forked from farhoodlabs/paperclip
Devin Foley
1f70fd9a22
## Thinking Path > - Paperclip orchestrates AI agents across isolated execution workspaces; the local cwd is the only persistence boundary between runs. > - Workspace lifecycle (worktree_prepare → execute → workspace_finalize) and the wake/accept flow are what guarantee that dependent issues see a consistent worktree. > - PAPA-380 / PAPA-431 / PAPA-432 / PAPA-440 surfaced three holes in that contract: silent env reuse across assignees, dependent wakes firing before finalize, and `issue.interaction.accept` advancing before finalize landed. > - PAPA-441 / PAPA-442 then needed to document the "no remote git" contract and prevent future adapter/runtime code from quietly reintroducing `git push` as a backdoor sync. > - This pull request lands those server fixes, the static `check-no-git-push` enforcement, the AUTHORING.md cross-link, and the Cody-review follow-ups on the PAPA-430 thread. > - The benefit is that finalize is a real barrier — board accepts, dependent wakes, and operator-set env all respect it — and adapter code can't bypass it via raw `git push`. ## What Changed - **server (PAPA-380, PAPA-431):** `execution-workspace-policy` refuses silent env reuse when the assignee's resolved env disagrees with the workspace it would inherit. The inheritance protection is now scoped to the actual inheritance signal — explicit issue-level `environmentId` is honored even when the agent's default env is `null`. - **server (PAPA-432):** `heartbeat.ts` gates dependent wakes on `listUnfinalizedExecutionWorkspaceIds`, and writes a `workspace_finalize` row on the succeeded path. Write failures now surface instead of being swallowed so dependents aren't silently stranded behind a missing row. - **server (PAPA-440):** `issue-thread-interactions.acceptInteraction` adds a workspace_finalize precondition for `request_confirmation` (not `suggest_tasks`). Accept returns 409 if finalize hasn't succeeded for the latest workspace operation. - **ci (PAPA-442):** new `scripts/check-no-git-push.mjs` static check scans `packages/adapters/`, `packages/adapter-utils/`, `server/src/`, and `cli/src/` for any `git push` invocation (string or args-array). Wired into the `policy` PR job and `test:release-registry`. Operators can opt in per-call with `// paperclip:allow-git-push: <reason>`. Release scripts are out of scope by design. - **docs (PAPA-441):** `AUTHORING.md` documents the no-remote-git contract and cross-links the static check so adapter authors learn the rule and the enforcement together. - **review follow-up (PAPA-430, Cody):** three fixes — env resolver bug, accept-gate scope (request_confirmation only), and finalize record write on the succeeded path. ## Verification - `pnpm exec vitest run server/src/__tests__/execution-workspace-policy.test.ts server/src/__tests__/issue-thread-interactions-service.test.ts` → 33/33 pass - `node scripts/check-no-git-push.test.mjs` → check covers string form, args-array form, comment exclusions, and per-line allow-comment. - Manual: server compiles; the policy job runs the check in <1s before heavier jobs. ## Risks - **Behavioral shift in accept:** boards accepting `request_confirmation` while finalize is in-flight now get 409s. This is intentional — they can retry — but it changes timing on a hot path. `suggest_tasks` is unaffected. - **Workspace policy:** the env-reuse refusal is a new error path. Issues that previously silently reused an env from a different-assignee workspace will now fail-loud; the resolver still honors explicit issue-level `executionWorkspaceSettings.environmentId`. - **CI rule:** any future legitimate `git push` in scoped dirs must be marked with the allow-comment, which is the intended ergonomic. ## Model Used - Claude Opus 4.7 (`claude-opus-4-7`, extended thinking), via Claude Code in the Paperclip executor adapter. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots (N/A — server/CI/docs only) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Closes related issues: PAPA-430, PAPA-380, PAPA-431, PAPA-432, PAPA-440, PAPA-441, PAPA-442 --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
86 lines
4.7 KiB
Markdown
86 lines
4.7 KiB
Markdown
---
|
|
title: Execution Workspaces And Runtime Services
|
|
summary: How project runtime configuration, execution workspaces, and issue runs fit together
|
|
---
|
|
|
|
This guide documents the intended runtime model for projects, execution workspaces, and issue runs in Paperclip.
|
|
|
|
Paperclip now presents this as a workspace-command model:
|
|
|
|
- `Services` are long-running commands that stay supervised.
|
|
- `Jobs` are one-shot commands that run once and exit.
|
|
- Raw runtime JSON is still available for advanced config, but it is no longer the primary mental model.
|
|
|
|
## Project runtime configuration
|
|
|
|
You can define how to run a project on the project workspace itself.
|
|
|
|
- Project workspace runtime config describes the services and jobs available for that project checkout.
|
|
- This is the default runtime configuration that child execution workspaces may inherit.
|
|
- Defining the config does not start anything by itself.
|
|
|
|
## Manual runtime control
|
|
|
|
Workspace commands are manually controlled from the UI.
|
|
|
|
- Project workspace services are started and stopped from the project workspace UI, and project jobs can be run on demand there.
|
|
- Execution workspace services are started and stopped from the execution workspace UI, and execution-workspace jobs can be run on demand there.
|
|
- Paperclip does not automatically start or stop these workspace services as part of issue execution.
|
|
- Paperclip also does not automatically restart workspace services on server boot.
|
|
|
|
## Execution workspace inheritance
|
|
|
|
Execution workspaces isolate code and runtime state from the project primary workspace.
|
|
|
|
- An isolated execution workspace has its own checkout path, branch, and local runtime instance.
|
|
- The runtime configuration may inherit from the linked project workspace by default.
|
|
- The execution workspace may override that runtime configuration with its own workspace-specific settings.
|
|
- The inherited configuration answers "which commands exist and how to run them", but any running service process is still specific to that execution workspace.
|
|
|
|
## Issues and execution workspaces
|
|
|
|
Issues are attached to execution workspace behavior, not to automatic runtime management.
|
|
|
|
- An issue may create a new execution workspace when you choose an isolated workspace mode.
|
|
- An issue may reuse an existing execution workspace when you choose reuse.
|
|
- Multiple issues may intentionally share one execution workspace so they can work against the same branch and running runtime services.
|
|
- Assigning or running an issue does not automatically start or stop workspace services for that workspace.
|
|
|
|
## Execution workspace lifecycle
|
|
|
|
Execution workspaces are durable until a human closes them.
|
|
|
|
- The UI can archive an execution workspace.
|
|
- Closing an execution workspace stops its runtime services and cleans up its workspace artifacts when allowed.
|
|
- Shared workspaces that point at the project primary checkout are treated more conservatively during cleanup than disposable isolated workspaces.
|
|
|
|
## Resolved workspace logic during heartbeat runs
|
|
|
|
Heartbeat still resolves a workspace for the run, but that is about code location and session continuity, not runtime-service control.
|
|
|
|
1. Heartbeat resolves a base workspace for the run.
|
|
2. Paperclip realizes the effective execution workspace, including creating or reusing a worktree when needed.
|
|
3. Paperclip persists execution-workspace metadata such as paths, refs, and provisioning settings.
|
|
4. Heartbeat passes the resolved code workspace to the agent run.
|
|
5. Workspace runtime services remain manual UI-managed controls rather than automatic heartbeat-managed services.
|
|
|
|
## Cross-run persistence (no-remote-git contract)
|
|
|
|
Code state moves between runs through the local execution-workspace cwd alone — not through a git remote.
|
|
|
|
- Each run's prepare step bundles the local worktree to the run's remote dir over ssh, with no `git remote` configured.
|
|
- The adapter's restore step at the end of the run writes any new remote commits back into the local worktree directly.
|
|
- Adapters must never `git push` from runtime code, and must never assume a remote exists.
|
|
- A failed restore is a run-level error and records `workspace_finalize=failed` on the execution workspace, which gates dependent issue wakes until the next successful finalize.
|
|
|
|
The invariant is enforced by the "no-remote-git contract" case in `packages/adapter-utils/src/ssh-fixture.test.ts`, which asserts a remote-only commit reaches the local worktree with no remote configured at any point.
|
|
|
|
## Current implementation guarantees
|
|
|
|
With the current implementation:
|
|
|
|
- Project workspace command config is the fallback for execution workspace UI controls.
|
|
- Execution workspace runtime overrides are stored on the execution workspace.
|
|
- Heartbeat runs do not auto-start workspace services.
|
|
- Server startup does not auto-restart workspace services.
|