Paperclip keeps setup-failure recovery inside a low-trust boundary

paperclipai/paperclip PR #11821 is the inspected primary source: “fix(recovery): preserve low-trust boundary on setup failure.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- paperclipai/paperclip PR #11821 was created 2026-08-20T22:41:35Z and was open at inspection; its title is “fix(recovery): preserve low-trust boundary on setup failure.” - paperclipai/paperclip issue #11820 was created 2026-08-20T22:27:08Z and was open at inspection; its title is “bug(recovery): keep setup-failure recovery inside low-trust boundary.” - paperclipai/paperclip PR #11824 was created 2026-08-20T23:17:56Z and was closed at inspection; its title is “fix(recovery): preserve source assignee on reblock.” - The repository reported 79007 stars, 5159 open issues, default branch master, and last push 2026-08-21T00:28:03Z. - The latest tagged-release baseline checked was v2026.817.0 published 2026-08-18T03:17:29Z.

What changed

paperclipai/paperclip PR #11821 reports: Thinking Path - Paperclip is the open source control plane for teams of AI agents. - Recovery routing keeps failed work owned and actionable. - Low-trust review places work inside an explicit trust boundary. - Setup-failure recovery currently uses the normal manager ladder before it resolves that boundary. - This can transfer recovery ownership and source assignment outside the bounded reviewer path. - This pull request resolves the effective trust policy before recovery routing. - The benefit is that recovery preserves the same low-trust boundary as execution. Linked Issues or Issue Description Fixes: #11820 Refs: #11655 Refs: #11658 What Changed Resolve the effective agent, project, issue, and run trust policy during stranded recovery. Keep an invokable bounded reviewer as the recovery owner and source assignee. Route recovery to the board when the bounded reviewer is unavailable. Preserve the source assignment during board fallback. Reject restored hand-back while the recorded return owner remains non-invokable. Add regression tests for both reviewer states after setup_failed. Verification RED on current master: the two new regression tests failed before the implementation. RED for Greptile P1: restoring to a paused return owner returned 200 and resolved the action before the hand-back gate was hardened. pnpm exec vitest run server/src/__tests__/issue-recovery-actions.test.ts --testNamePattern 'low-trust review recovery|bounded low-trust recovery' — 2 passed. pnpm exec vitest run server/src/__tests__/issue-recovery-actions.test.ts --testNamePattern 'low-trust review

paperclipai/paperclip issue #11820 reports: Pre-submission checklist [x] I have searched existing open and closed issues. This issue supersedes #11655 because its PR contains unrelated changes and is stale against current master. [x] I can reproduce this on current master. [x] I confirmed that the error originates in Paperclip core recovery routing. What happened? A stranded issue inside an active low_trust_review boundary can leave that boundary after an adapter setup failure. resolveStrandedRecoveryRouting uses the normal manager ladder for setup_failed. It does not resolve the effective agent, project, issue, and run trust policy first. The recovery action therefore assigns the manager as owner. The source issue can also lose the bounded reviewer assignment. This behavior violates the active low-trust boundary and can cancel the intended reviewer retry through the normal assignee-change path. Expected behavior Recovery must preserve the active low-trust boundary. If the bounded reviewer is invokable, that reviewer remains the recovery owner and source assignee. If the bounded reviewer is not invokable, Paperclip creates board-owned recovery work without transferring the source issue to a manager. The recovery path must use the effective trust policy from the agent, project, issue, and run. Steps to reproduce 1. Create an issue assigned to a reviewer. 2. Set the issue authorization policy to low_trust_review. 3. Set a trust boundary that includes the issue and allows the reviewer. 4. Escalate

paperclipai/paperclip PR #11824 reports: Thinking Path - Paperclip manages agent work and recovers stranded runs. - This change is in the server recovery path for stranded assigned issues. - Recovery can create a source-scoped recovery action when a run fails under another agent. - The bug is that this path can overwrite issues.assigneeAgentId with the recovery actor. - That breaks standing-sink ownership and causes false ownership changes during review recovery. - This pull request keeps the source assignee by default and keeps explicit reassignment only for the narrow review-takeover path. - The benefit is stable issue ownership during recovery with the existing review flow preserved. Linked Issues or Issue Description Related PRs searched on GitHub: #11794, #10480. What happened?** Recovery reconciliation could overwrite issues.assigneeAgentId with the recovery actor during terminal-run recovery or stale re-block. Expected behavior** Recovery should keep the current source assignee unless the execution-review state still explicitly returns ownership to the same recovery owner. Steps to reproduce** 1. Start with an in_progress or in_review issue assigned to agent A. 2. Let recovery run under agent B after a failed run or stale re-block path. 3. Observe that the source issue assignee switches to B instead of staying on A. Paperclip version or commit** c0e49c73b Deployment mode** Built from source (pnpm workspace checkout) What Changed Keep originalAgentId anchored to issue.assigneeAgentId before falling back

Why it matters

Failure recovery is exactly when systems are tempted to broaden authority to get unstuck. Preserving trust posture and assignee provenance prevents a setup error from silently becoming an escalation path. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-21. The tagged-release baseline was v2026.817.0 published 2026-08-18T03:17:29Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/paperclipai/paperclip/pull/11821. Supporting records are https://github.com/paperclipai/paperclip/issues/11820 and https://github.com/paperclipai/paperclip/pull/11824. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Recreate recovery work with the original trust level and assignee, require explicit authority changes, and verify restart does not rewrite those fields. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.