Paperclip moves three invisible-work failures into explicit ownership rules

paperclipai/paperclip PR #10920 is the inspected primary source: “feat(interactions): backfill dead board asks + per-issue pending soft cap (RBR-791).” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- paperclipai/paperclip PR #10920 was created 2026-08-05T21:58:53Z and was open at inspection; its title is “feat(interactions): backfill dead board asks + per-issue pending soft cap (RBR-791).” - paperclipai/paperclip PR #10921 was created 2026-08-05T22:05:26Z and was open at inspection; its title is “fix(issues): auto-assign a wakeable owner on issue create (RBR-767).” - paperclipai/paperclip PR #10922 was created 2026-08-05T22:06:21Z and was open at inspection; its title is “Make routine issue retries idempotent.” - The repository reported 75706 stars, 5003 open issues, default branch master, and last push 2026-08-06T00:59:56Z. - The latest tagged-release baseline checked was v2026.722.0 published 2026-07-22T23:05:41Z.

What changed

paperclipai/paperclip PR #10920 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Agents work a shared issue board, and the board's decision queue (pending interactions — confirmations, question sets, suggested tasks) is the mechanism the board and humans use to unblock agents - Agents could create board interactions but had no way to retire their own, so pending rows piled up on issues that were already done/cancelled and could never be answered - Auto-void-on-close and author-scoped withdrawal already ship on master (#10251, #10252), but only fire going forward — rows filed before those landed are permanently stuck as exhaust, inflating the board's queue and hiding the real decision count - This pull request backfills the pre-existing dead rows with the exact outcome the runtime hook now produces, adds a per-issue pending soft-cap warning so runaway ask behavior is attributable, and replaces the queue-depth script

paperclipai/paperclip PR #10921 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work. - The issue-creation subsystem (server/src/routes/issues.ts, both POST /companies/{id}/issues and POST /issues/{id}/children) accepts assigneeAgentId and assigneeUserId as optional fields. - When both are omitted or explicitly null, the created issue has no owner. No heartbeat ever wakes on it, regardless of priority, so the issue becomes permanently invisible to the org. - This is not hypothetical: on this deployment, a critical issue on the certification critical path sat unassigned and untouched for 26 days before anyone noticed, and the failure reproduced again the same day it was first fixed manually. - This pull request makes the defect impossible to create: both routes resolve a deterministic, wakeable fallback owner (parent's assignee -> creator's nearest invokable manager -> creator -> company root) before insert, and reject the create with 422 only in the floor case where

paperclipai/paperclip PR #10922 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work. - Scheduled routines create issues that agents use as operator actions. - Routine dispatch stores a run row and creates an issue. - These writes use separate database transactions. - A failed outer transaction can leave the issue committed without the run row. - A retry can then create another issue for the same dispatch. - This pull request gives issue creation a durable routine dispatch key. - The benefit is one issue for one idempotent routine dispatch. Linked Issues or Issue Description What happened?** A routine issue could commit in its own transaction. The outer routine transaction could then roll back. A retry checked only the missing routine run row and created another issue. Expected behavior** A retry with the same routine idempotency key must return the first issue. It must not

Why it matters

An agent control plane is only as truthful as its ownership and idempotency rules. A critical card can exist for 26 days without a wake target, while a retry can duplicate an issue after its run row rolls back. The operator test is whether persisted state, execution authority and the visible outcome describe the same event after retries, restarts or delegation.

Current

The primary record was open when captured on 2026-08-06. The release baseline was v2026.722.0 published 2026-07-22T23:05:41Z. Repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/paperclipai/paperclip/pull/10920. Supporting records are https://github.com/paperclipai/paperclip/pull/10921 and https://github.com/paperclipai/paperclip/pull/10922. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly 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

Apply the migration with a scoped backup, verify the fallback ladder and 422 floor, and prove one routine key maps to one issue across partial failure. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

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.