Paperclip defines a package release boundary for its runner

paperclipai/paperclip PR #12129 is the inspected primary source: “feat(runner): define package release boundary.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- paperclipai/paperclip PR #12129 was created 2026-08-24T22:55:31Z and was open at inspection; its title is “feat(runner): define package release boundary.” - paperclipai/paperclip PR #12127 was created 2026-08-24T21:57:54Z and was open at inspection; its title is “fix(interactions): free an idempotency key when its interaction goes terminal.” - paperclipai/paperclip PR #12123 was created 2026-08-24T21:08:06Z and was open at inspection; its title is “feat(fallback): fail a provider-quota run over to the next Claude subscription.” - The repository reported 79312 stars, 5359 open issues, default branch master, and last push 2026-08-25T00:18:58Z. - The latest tagged-release baseline checked was v2026.817.0 published 2026-08-18T03:17:29Z.

What changed

paperclipai/paperclip PR #12129 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work. - The runner package now has protocol, provider, catalog, and authorization foundations. - The server cannot depend at runtime on a private workspace package. - Package consumers need explicit and testable exports. - Release and container builds need the same runner verification boundary as pull requests. - This pull request defines the initial package and server vendoring boundary. - The benefit is a clean Codex-first package surface without exposing deferred SDK or lab work. Linked Issues or Issue Description Refs #11962 This pull request replaces one bounded part of the archived large runner change. It follows the package-local authorization change in #12126. What Changed Export only @paperclipai/paperclip-runner and @paperclipai/paperclip-runner/testing. Keep Node-only fixture loading and semantic conformance helpers out of the runtime root. Add a provider-neutral semantic conformance kit with stable JSON comparison and fail-closed input checks. Keep the runner package private and omit deferred SDK, eval, browser, React, lab, and command surfaces. Pack and install the runtime dependency closure in an isolated offline consumer test. Verify the package inventory and prove that deferred subpaths do not resolve. Add a server development shim and vendor the built runner distribution into the server output. Preserve an existing vendored distribution when the source build is absent.

paperclipai/paperclip PR #12127 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Issue-thread interactions are the gate cards an agent puts on an issue: request_confirmation, ask_user_questions, suggest_tasks. An agent creates one with an idempotencyKey so a retried heartbeat does not post the same card twice. - A pending request_confirmation is expired when a user comments on the issue (supersedeOnUserComment). The row goes to status = "expired", but it keeps its idempotency key. - The idempotency lookup ignores status, and the unique index behind it covers every row with a non-null key. The dead row therefore stays the owner of that key. - The agent cannot ask the question again on that issue. An equivalent retry gets 200 and the already-expired interaction. A changed retry gets 409. No release has a withdraw route, so the key is lost for good. - This pull request scopes the lookup and the unique index to status = 'pending'. A terminal row keeps its key for the audit trail but no longer owns it. - The benefit is that a superseded gate can be asked again. Idempotency for the live case does not change. Linked Issues or Issue Description Describe the bug** An interaction that ends in a terminal status keeps its idempotency key forever. The key cannot be

paperclipai/paperclip PR #12123 reports: Thinking Path - Paperclip runs AI agents whose intelligence comes from a subscription/provider adapter (e.g. claude_local). - When that source hits a provider quota / rate limit, a run fails with errorCode: "provider_quota" and recovery reschedules the retry to wait out the reset window (up to an hour). - Operators who hold more than one subscription would rather have the agent switch to a second subscription immediately than idle until the window clears — like a fallback provider chain. - There was no way to express "if source A is exhausted, use source B": model profiles override config but can't switch auth, and no fallback-chain scaffolding exists on master. - This pull request adds a per-agent runtime_config.fallbackChain and fails a quota-exhausted run over to the next **same-provider** source (a second Claude subscription — same adapter, different token) immediately instead of waiting. - The benefit is continuity: agents keep working across a quota wall by rolling to the operator's next subscription, with no idle window. Issue (described in-PR, Enhancement) _No public GitHub issue existed; describing it inline per CONTRIBUTING.md, following the Enhancement template._ **Existing behavior improved:** provider-quota recovery for a run (heartbeat.ts transient-continuation reschedule and the provider-quota wait monitor in recovery/service.ts). **Subsystem affected:** server / heartbeat run scheduling + recovery. **Current behavior:** a provider_quota failure reschedules the same source at the

Why it matters

Release identity, interaction deduplication and provider failover all decide whether a recovered run is the same run or an accidental duplicate. 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-25. 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/12129. Supporting records are https://github.com/paperclipai/paperclip/pull/12127 and https://github.com/paperclipai/paperclip/pull/12123. 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

Sign the runner package boundary, release idempotency keys only at terminal state, and preserve one run identity across subscription failover. 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.