PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-11-01 23:43:16 +01:00

Author	SHA1	Message	Date
DottaandPaperclip	198218bf55	fix(config): require shared storage for managed cloud (#18350 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Managed Cloud instances must retain shared objects and secrets across server replacement. > - Implicit storage defaults can select local disk or an unintended bucket. > - Cloud runtime settings now come from a canonical database snapshot. > - This pull request validates bootstrap prerequisites before database setup and effective S3 settings after snapshot resolution. > - The benefit is an actionable refusal before local signing state or HTTP setup, while valid canonical Cloud settings work. ## Linked Issues or Issue Description What happened? A managed Cloud instance could start with local disk storage, an implicit bucket, or a local key file. After canonical Cloud configuration landed, checking only environment or file values would also reject a valid database bucket. Shared schema defaults could make an omitted raw bucket appear explicit. Expected behavior Managed Cloud requires external PostgreSQL, a stable environment master key, and effective S3 settings with a nonblank bucket. The canonical snapshot remains the configuration authority. Invalid configuration refuses startup before signing or HTTP effects. Self-hosted defaults remain compatible. Steps to reproduce 1. Select managed Cloud with its tenant token or managed configuration document. 2. Leave storage as local disk, or omit the S3 bucket from a raw canonical snapshot. 3. Start the server. Startup must refuse. An explicit valid bucket in the canonical snapshot must work without a file or environment bucket. Paperclip version or commit Current base: `4edd10804e2b42941aa2038e90c362c13a0b98dc`. Deployment mode Managed Cloud. Ordinary self-hosted defaults remain unchanged. Related PRs: #18335 owns canonical Cloud runtime configuration. #18327 owns S3 run logs. #18352 owns credential persistence. #18347 owns cutover checks. This PR adds configuration prerequisites to those existing boundaries. ## What Changed - Validate external PostgreSQL and a stable environment master key at the Cloud bootstrap boundary, before database setup. - Validate effective S3 settings after canonical snapshot publication and before Cloud signing, runtime consumers, or HTTP setup. - Require a nonblank bucket in the Cloud snapshot schema. Reject omitted or blank buckets in every legacy Cloud file before one-time import normalization, even when an environment bucket is supplied. Keep shared self-hosted schema defaults. - Preserve typed bucket provenance at the existing file-read boundary. Accept explicit canonical bucket names, including `paperclip`, and environment settings when the snapshot is null. - Validate effective legacy storage with the existing resolver before seeding. A rejected candidate leaves no canonical rows, so a corrected source file can be imported on retry. Environment overlays are checked but never persisted. - Add real PostgreSQL snapshot and migration-retry tests, startup refusal tests, and environment/file compatibility controls. Document that Cloud always requires its stable environment key, even with an external default secrets provider. ## Verification - Latest focused acceptance passed 199/199 in six files (54.29 seconds), using the command below plus `server/src/__tests__/cloud-configuration-migration-postgres.test.ts`. Real PostgreSQL proves rejected storage leaves all three migration authority rows absent, then a corrected legacy file imports on retry. An external-default-secrets control proves the deliberate unconditional Cloud master-key contract. - Before the peer correction, the frozen product diff passed 178 tests in five files: managed-cloud-prerequisites, cloud-runtime-config, server-startup-feedback-export, config-file, and cloud-configuration-readers. Command: `pnpm exec vitest run server/src/__tests__/{managed-cloud-prerequisites,cloud-runtime-config,server-startup-feedback-export,config-file,cloud-configuration-readers}.test.ts --maxWorkers=1 --no-file-parallelism`. Real PostgreSQL used a qualified POSIX test-only PG18.6 override because the host cannot supply the stock runtime's SysV semaphore allocation. - Coverage includes raw database and legacy omitted/blank bucket rejection, valid database and environment buckets, null snapshots, explicit default-named buckets, self-hosted compatibility, and refusal before local signing mutation. - The real AWS SDK configured-provider control uses a simulated loopback S3 service. It writes, reads from a fresh provider, and deletes an object. It also reads an encrypted credential with the stable environment key. This does not qualify production cloud permissions. - `git diff --check` passed. Final merges add unrelated master changes from #18241, #18363, and #18370; the focused storage product diff is unchanged. - Peer review reproduced a fresh legacy local-disk import that gained the default bucket before an S3 environment overlay. The importer now requires a raw explicit bucket for every legacy Cloud file. Six controls cover omission/blank values with and without an environment bucket; the full focused rerun passed 184/184 across all five files in 194.89 seconds. - Initial revised startup testing passed 167/168: one fixture omitted the database URL and failed before its intended key assertion. The corrected final run passed 178/178. An initial direct server typecheck failed because Runner declarations were not built; this is a setup failure, not a compile pass. Integration verification rebuilds dependencies before full checks. - Prior head `fae1e4aa` passed complete CI with 53 successes, two intended skips, and Greptile 5/5. `de71345f379cecb71dbfb219f35e14f942c10a3f` then passed complete CI (55 successes, three workflow skips, and a neutral external review), with Greptile 5/5 and zero unresolved threads. The external review identified the preseed rejection problem; its correction is committed at `75e04d0d77e19dcef0a8cb070b6b518f0f173b14`. The final merge head is `19b809ea2823a6a4e5ceb48ef2c2bac4721733d6`; [Fresh complete CI](https://github.com/paperclipai/paperclip/actions/runs/41127309762) passed on that head: 55 successful checks, three workflow skips, and one neutral external review. Greptile reviewed this exact head at 5/5 with no actionable issues. Both earlier external review threads are resolved with the tested fixes. Earlier infrastructure retries remain documented in [the first diagnosis](https://github.com/paperclipai/paperclip/pull/18350#issuecomment-6529964690) and [the runner shutdown evidence](https://github.com/paperclipai/paperclip/pull/18350#issuecomment-6530364769). Earlier missing SDK build and fixture metadata failures were repaired before those passes. - Current frozen-head CI first attempt failed one unchanged Antigravity authentication success case in Runner Vitest 1/2 (`outcome=failure`, 1994 tests passed). The same file passed 11/11 locally in 2.33 seconds, and identical Runner source passed the prior complete CI run. Attempt 2 retried only failed jobs (the Runner shard and dependent aggregate). Both passed without a source change. No second retry was used. The exact timing cause is not established. [Failed job](https://github.com/paperclipai/paperclip/actions/runs/41127309762/job/124309181778). - No production data, buckets, or live credentials were used. Complete local repository suites are not duplicated in this worktree; current-head required CI supplies the full suite gate. ## Risks - Managed deployments with local disk, omitted buckets, file-only keys, or missing external database URLs now refuse startup. Operators must supply valid prerequisites before rollout. - Required deployment environment overlays must remain stable across replacements. For example, a saved local-disk provider with an explicit bucket can use an environment S3 provider; removing that required overlay correctly refuses startup until the environment or canonical configuration is corrected. Environment settings are never silently copied into the canonical row. - Effective legacy storage must also pass before first seeding. A bad candidate does not create authority rows. Existing saved rows remain authoritative and can require environment overrides or a canonical configuration change if they are invalid. - A present legacy Cloud file needs an explicit raw bucket even if its saved provider is local disk or its environment supplies a bucket. Correct the file before one-time import, or use the existing absent-file/null-snapshot environment-only setup. Environment overlays are not persisted as operator choices. - A previously stored canonical nonblank `paperclip` bucket is authoritative. Prior normalization erased whether that value was originally explicit. This change cannot recover that provenance and does not reject existing nonblank canonical values. - Validation proves configuration shape, not cloud permissions, database reachability, or key compatibility with existing encrypted data. Keep the master key stable across replacements. - Cloud snapshot JSON parsing is stricter; omitted or blank raw S3 bucket values need correction. No database migration or provider operation changes are added. These prerequisites do not prove that every server persistence path is disposable. > 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, exact model ID `gpt-6.1-sol`. Context window: unknown. The model used reasoning, repository tools, code execution, and test execution. ## 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>	2026-10-30 16:21:46 -05:00
DottaandPaperclip	0e15c92073	feat(skills): make managed content independent of web-server disk (#18334 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agents use installed skills and exact version pins during execution. > - Managed skills still depended on mutable directories on the web server. > - A replacement server could lose acknowledged edits or remove an unassigned skill whose directory was absent. > - This pull request makes immutable versions the authority for managed content and installed repository reads. > - The server can rebuild delivery files from durable content after replacement. > - This establishes skills readiness for ephemeral web servers. General server draining and workspace recovery remain separate work. ## Linked Issues or Issue Description Subsystem affected Skills services, shared contracts, database receipts, Skill Studio, and runtime delivery. Problem or motivation A fresh web server must discover, read, edit, and deliver protected installed skills using the same database, object storage, secrets, and supported application artifacts. It must not need its predecessor's files or process memory. Proposed solution Use `managed` ownership with a null source locator. Read installed content by immutable version. Prepare packages before a short publication transaction. Persist execution selections before materialization. Recover exact pinned runtime assets and reject deletion while active or recovering pins exist. Alternatives considered Reconstructing a mutable installed directory preserves the old source-of-truth ambiguity. Permanent dual writes create two competing authorities. This change uses one managed model after a bounded legacy conversion. Roadmap alignment This improves the existing Skills Manager, Studio, version history, and Cloud execution capabilities. The maintainer supplied the implementation contract. This does not add a separate skills product or deploy fleet changes. Related work: #18082 supplies immutable package storage. #17273 addresses edits outside the API for linked local skills; this PR keeps that source category separate. #2648 is a closed earlier ephemeral-filesystem proposal. ## What Changed - Add managed ownership and focused content publication and execution materialization modules. Keep the archive format and package storage tables. - Publish managed create, save, delete, fork, rename, restore, and catalog content with version checks. Add durable create receipts. Preserve file-save receipt responses. - Return file version identities. Keep Studio drafts after a conflict and provide an explicit reload action. A delayed reload cannot overwrite newer typing or navigation. - Persist exact runtime selections, including empty selections. Rebuild pinned assets and verify their admitted digests on a replacement server. - Preserve source access on forks and disconnected copies. Keep the existing workspace policy category for managed skills. - Add bounded conversion, eligibility, and independent verification phases. Load persisted Cloud configuration in the standalone CLI without seeding or changing it. Reject partial current versions against installed inventories; recover only complete saved content or the exact source. Document storage migration blockers and the compatible rollback floor. - Add separate-process PostgreSQL/S3 qualification and update domain, retention, policy, and UI regressions. - Pass the plugin worker manager into Studio execution, admit restricted `skill_test` mode through native Runner contracts, and preserve admitted scope across native and REST tools. Native tests cannot create ordinary tasks, browse company data, or use external tools. - Select the exact durable Studio revision even when unassigned or Beta skills is off. Persist Studio output and audit atomically with native task completion, preserving the result on replay. ## Verification - Final revision `13e8af480b88ba6fea5737bac4bd81104d604792` passed full CI: all 49 workflow jobs completed successfully ([run 41127396098](https://github.com/paperclipai/paperclip/actions/runs/41127396098)). This includes typecheck, test suites, Runner checks, browser checks and build. Greptile review 15 is 5/5 on that same revision, with zero unresolved threads. The PR is ready for review. - Local workspace typecheck and build passed after integrating master. Focused checks passed: 33 execution/completion cases, 52 Runner HTTP cases, 16 managed-content cases, 17 Studio cases, the new real-process CLI regression, map checks and UI token gates. The CLI regression proves inspection does not seed missing Cloud configuration. Server typecheck passed after that fix. - The independent-process PostgreSQL/S3 matrix passed through normal HTTP skill routes. It covers A → B → C replacement, lost commit responses, upload crashes, concurrent saves, binary contents and executable delivery. Metadata listing and warm selected delivery retain zero object downloads. Local timing measurements are recorded; they do not establish hosted latency. - Hosted A → B → C passed on the owned disposable test tenant with external Postgres, S3 and a real remote Paperclip Computer. Predecessor temporary homes were absent. C read and executed B's acknowledged managed save. New runs used repository v1 while v2 was installed. Hashes matched an independently checked exact upstream commit. - Compatible image rollback to `6518b323` passed. Studio retained the unassigned fork's C save. A fresh remote run executed the newer managed content and historical repository pin. The actual shell event confirmed expected hashes, stdout, exit 0 and mode 0555. - Runtime candidate `9200e3fcb4` deployed successfully ([Cloud run 41124147876](https://github.com/paperclipai/paperclip-cloud/actions/runs/41124147876)). The final Studio test delivered only the unassigned fork's exact v3, executed its script and persisted a successful output snapshot. Independent command-event inspection confirmed all three hashes, stdout, exit 0 and mode 0555. All 14 installations were version-backed. Independent verification checked all 25 versions: 23 remote objects, two bundled database snapshots, zero blockers. - The deployed image is `9200e3fcb4`. Later master integration, the client-only delayed-reload draft guard and the CLI bootstrap have separate automated proof. The CLI bootstrap was also exercised against the tenant's stored configuration and storage through the same read-only services. This PR does not claim that the deployed image is the final PR revision. - Live Studio checks exposed worker wiring, admission, access scope, exact selection and completion-publication gaps. They are fixed. Failed attempts remain in the evidence. The full local suite exceeded 80 minutes under host contention and was stopped. Later combined/isolated local attempts also timed out; they are not counted as passes. Full CI covers the integrated suites. Earlier CI found an obsolete restart-scope fixture, which was corrected and passed all 52 HTTP cases. - Reproduction and migration: [`doc/skill-ephemeral-web-servers.md`](doc/skill-ephemeral-web-servers.md). Source revisions, deployments, versions, run IDs, hashes and failure history: [`doc/plans/2026-10-30-ephemeral-web-skills.md`](doc/plans/2026-10-30-ephemeral-web-skills.md). ## Risks - Legacy conversion requires stopped admission and retired filesystem-authoritative writers. Pre-conversion binaries are not supported rollback targets afterward. - Cloud readiness requires remote object storage. Local provider receipts and provider mismatches remain blockers until objects are copied and verified. - Linked local sources retain filesystem semantics and are outside the cloud guarantee. - Cold reads still fetch the existing archive format. Warm runtime preparation retains the verified-cache path. - Bundled reconciliation preserves an installed head. Existing release snapshots remain selectable. An older server must not replace a newer head with its shipped files. - No production volumes, fleet defaults, or general deployment coordination change in this PR. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools, code execution, and browser use. The exact backend model ID and context-window size are not exposed in this session. No subagents were used. ## 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>	2026-10-30 16:18:27 -05:00
DottaandPaperclip	56957f2bd9	fix(ci): isolate test selection and require current CI CODEOWNERS (#18376 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - PR CI selects affected suites and test files to reduce feedback time. > - A selected test inherited the parent selection when it launched an independent runner fixture. > - Ordinary source filenames containing config or setup also forced broad coverage. > - AWS runner access must depend on current CI CODEOWNERS, not only a stored numeric roster. > - This pull request fixes both selection problems and verifies owners before AWS allocation. > - Contributors retain GitHub-hosted CI. Authorized maintainers retain AWS test and final verification jobs. ## Linked Issues or Issue Description Refs #18362 and #18348. The selected server run for #18369 failed in `vitest-chat-shards.test.ts` because its temporary fixture inherited `PAPERCLIP_CI_TEST_SELECTION` and attempted `git rev-parse HEAD` outside a Git repository. #18366 could not use graph selection because `session-config-metadata.test.ts` matched the broad filename rule. The AWS setting was already enabled. The reviewed outsider PRs correctly used hosted runners; a maintainer PR used AWS, including final verification. This change strengthens that boundary rather than enabling AWS for outsiders. ## What Changed - Remove selection settings from Vitest child environments after the wrapper validates the selected shard. - Match conventional Vite/Vitest configuration filenames rather than any occurrence of config or setup. Keep graph tracking for actual setup and configuration dependencies. - Bind rerun actor lookup to the exact run attempt. Require the author, event sender and rerun actor to be current CI CODEOWNERS and members of the existing numeric allowlist. Read the resolver and CODEOWNERS from one protected master revision. - Run metadata authorization on GitHub-hosted capacity before any AWS allocation. Keep authorized test and final verification placement on the AWS fleet. - Add a real selected-server regression that launches nested chat fixtures, negative authorization cases, and qualification for a real config-named test. - Update the developer and profiling guides. - Retire eight legacy PR workflow SHA authorizations and one deleted qualification-branch reference from the live `paperclip-public-pr` runner group. The remaining three references are the trusted PR workflow and the existing full-stack/protocol evaluation workflows on master. No active PR run referenced the retired versions. ## Verification - Selection regression tests: 13 passed, including the real nested chat runner. - Routing, planner and profiling tests: 100 passed, including 69 routing cases. - `actionlint` passed for both changed workflows. `git diff --check` passed. - Confirmed protected master still requires CODEOWNER review. A live lookup found four CI owners, with three of six numeric roster entries eligible and three denied by the new owner check. - `pnpm -r typecheck` and `pnpm build` passed. The full local Vitest suite was stopped after repeated embedded PostgreSQL initialization failures; it did not pass. On final revision `0b40ae15b7996603e405edd4157a5c337e0405c7`, both Linux qualification jobs and all required CI gates passed. The main PR workflow completed with 48 successful jobs and one intentional skip, including final verification. [CI run](https://github.com/paperclipai/paperclip/actions/runs/41126881716). Greptile reviewed the final revision at 5/5 with no inline findings. - Shard and workflow contracts: 44 passed. CI first caught an outdated assertion that required the routing job to use AWS; it now requires hosted authorization, and the policy job passes. - A read-only live gate exercise preserved the existing merge-freshness denial when master advanced beyond the available merge ref. It allocated no runner and was not a successful admission proof. ## Risks - The short metadata authorization job now depends on GitHub-hosted queue capacity. This prevents a stale roster from allocating AWS before current CODEOWNERS are checked. Authorized test and final verification jobs still use AWS. - Identity/API failures fall back to hosted CI. No caller can override the trusted owner list with PR contents. - Configuration dependencies still require conservative graph handling. Existing setup dependency, opaque I/O, stale manifest and wrong-lane tests remain in place. - The runner group is restricted to selected repositories and selected workflows. Its workflow allowlist was verified and narrowed through the GitHub settings UI. Legacy pinned callers must update to the current trusted workflow before using AWS; active PR runs used master references. The current PR workflow authorization and evaluation workflow authorizations remain in place. ## Model Used - OpenAI Codex, based on GPT-6. The exact serving variant and context limit are not exposed in this session. Used reasoning, repository inspection, code execution and GitHub 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 — targeted suites passed; the full local suite hit the PostgreSQL startup limitation documented above, and full Linux CI passed - [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>	2026-10-30 16:10:40 -05:00
DottaandPaperclip	dbff3747b8	feat(server): persist run logs and provider traces in S3 (#18327 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Operators use run logs and restricted provider traces to inspect agent work. > - Local log and trace files depend on the web server's persistent volume. > - That dependency prevents overlapping volume-backed Railway deployments. > - This PR reuses the instance S3 store for batched log and trace payloads with conditional publication. > - Existing Postgres rows retain their contracts; native export recovery reuses events already committed before Runner acknowledgement. > - S3-configured servers automatically copy and verify retained history before a later deployment cutover. ## Linked Issues or Issue Description Subsystem affected Server run logs, restricted provider traces, storage providers, and migration tooling. Problem or motivation Replacing the web server and its disk must preserve committed log output and retained traces. The current S3 mirror can repeatedly upload a growing file. Moving those payloads into Postgres would add database writes, WAL, replication, and backup work. Proposed solution Reuse the existing instance storage configuration, S3-compatible provider and credential chain. Store new run logs under run-logs/ and opted-in raw traces under provider-traces/, below the existing prefix. Cloud keeps its existing bucket and bucket-scoped credentials per stack. Add no new configuration switches. Store immutable payload segments and bounded binary range indexes directly in S3. Publish each batch with an ETag-conditional head. Keep existing database ownership and lifecycle records. Recover canonical native exports from their existing validated control event source, checkpointing export progress in S3. Add no new payload writes to Postgres. Preserve local defaults and migrate settled history with verified byte counts and digests. Alternatives considered Postgres payload chunks add control-plane load. Repeated whole-file mirrors amplify transfer work. The first index prototype left superseded index nodes; the final binary index keeps all normally published nodes reachable. Roadmap alignment This is a storage prerequisite for replacing the main web/API server. It does not enable deployment overlap, detach a volume, or change native Runner protocol acknowledgements. The maintainer approved this implementation scope. ROADMAP.md has no duplicate implementation item. Related PR: #16770 improves the existing in-flight mirror. This PR preserves that legacy backend and uses the existing instance S3 profile for new journals. ## What Changed - Automatically select S3 segments for new logs and opted-in traces when instance file storage uses S3. Reuse bucket, endpoint, region, prefix, path style and credentials. Remove separate backend switches. Keep local-disk instances local. - Share the existing storage configuration resolver with product files. Preserve config-file settings, environment precedence and the existing root prefix. Keep pre-existing run-log mirror settings for legacy history. - Add bounded buffering, conditional ownership fencing, immutable range reads, stable byte offsets, and completion hashing. - Dispatch all existing log consumers through the recorded backend. Coalesce output progress writes and publish live log messages after storage receipts. - Recover interrupted canonical native exports from their existing durable source. Exclude separate credential, cleanup, and reprojection records. Replay missing callback ranges and deduplicate late delivery. Repair settled archives after controller lease expiry. Bound shared repair work and stop it when all readers cancel. Serve the published prefix when best-effort repair fails. - Add encrypted optional trace channels, replacement reads, durable deletion tombstones, and deadline-driven local/external expiry cleanup independently of heartbeat scheduling. Stream historical source and remote verification. Propagate worker cancellation through trace open, conditional-write probing, upload, restore and reads. Fence deletion even before the first object head exists; abort and drain owned captures. - Retry transient storage errors, distinguish 409 from failed preconditions, and backpressure bounded log admission. Track interrupted trace imports explicitly so ordinary local deletion stays independent of S3. - Automatically migrate retained history through the existing delivery coordinator. Process one log and one trace per batch. Retry unresolved history with backoff and stop scans after completion. Keep the inventory/import command as optional diagnosis and repair. Verify source and remote bytes before switching references. Verify finalized native size and digest before setting its export cursor. Require ordered source coverage when completeness metadata is missing. Preserve original trace expiry. Block active, missing, corrupt, and unproven sources. - Preserve identity and run-secret redaction in live and recovered native logs. Register runtime log redaction secrets once through the existing encrypted registry. Keep agent private keys in their existing owner. - Add storage, migration, retention, UTF-8, and route-privacy coverage, plus operating documentation and qualification tooling. - Add no schema, payload table, per-record SQL, production dependency, or lockfile change. ## Verification - Final fixes at `b3a44c898e` passed all 116 selected startup, retention, attribution and cancellation controls. The disabled-scheduler cleanup and concurrent-repair defects reproduced red before the fixes. A timed-out repair still prevents later storage reads. - The merged source passed 124 storage and real-Postgres Cloud configuration tests. These include automatic history migration, existing environment/file vault keys, source-directory removal, five real-SDK stalled-request cancellation cases, shared capability-probe cancellation and multi-chunk trace ordering. Saved Cloud S3 settings work after the legacy config file is gone. - Workspace typecheck and full build passed at the merged parent `19f702d780`. Server typecheck and build passed again at `b3a44c898e`. - Actual app acceptance: finish a process-agent run through the normal API, stage its retained local-file input, then restart. Automatic migration reports one migrated item and zero blockers. Remove the original web home and restart at `b3a44c898e` with an empty home, the existing S3 profile and the existing vault key file. The normal log API preserves all five producer lines and exactly 788 bytes, with SHA-256 `74d9ae469da28bfe89b9b50a0e132aec24fe9e6d686496ed5e4ffa6167151036`. No log-specific storage settings are present. - Actual expiry acceptance: with heartbeat scheduling disabled, a trace remains unexpired after startup and later reaches its fixture deadline. The worker marks the row deleted and tombstones both S3 channel heads. The retained run log stays byte-identical. The process fixture emits no provider protocol frames, so nonempty encrypted payloads are qualified separately through the real SDK round trips. - Isolation tests use identical run identities in two stack buckets. Cleanup in one existing prefix leaves another prefix, another company and product files intact. Read-only Cloud source inspection confirms a bucket and bucket-scoped credentials per stack. Four existing Cloud storage environment-contract tests passed. No Cloud provisioning changed and no new live vendor permission probe was performed. - Earlier qualification passed 1,014 affected storage/native tests and 27 privacy-route tests with isolated Docker Postgres. An abrupt process test commits 1,000 records, receives receipts, dies by SIGKILL and loses its directory; another process reads every byte and continues. The real Rust Runner experiment acknowledges 32 records while the export cursor is zero, then continues the same Runner PID after controller loss. All 64 records export once with exactly 64 existing control rows. Repeated snapshot/Stop commands completed in 162/81 ms. - Emulator workload: 1,000 burst records used two batch PUTs. Eight steady streams produced 240 records with 104 conditional PUTs and 72 GETs over 6.9 seconds. These are synthetic operation counts, not fleet sizing or provider prices. - Failure evidence is retained. Compact native events over 64 KiB, missing file-key support, disabled-scheduler retention and repair failure handling all reproduced before their fixes. Fixture repairs addressed cold module setup, localhost/IPC permissions, the S3 bucket-name limit and a mode-0700 crash-test directory. Full local `pnpm test:run` was stopped after host PostgreSQL semaphore exhaustion; affected suites used isolated Docker databases instead. Native package library symlinks were restored with the package's standard hydration helper. - The `19f702d780` browser session-recovery case timed out while saving a task title. All eight browser shards passed on `b3a44c898e`, including that case, with no UI behavior or assertion change. Fresh-head CI passed at `b3a44c898e`: 55 successful checks, three skipped checks and one neutral check. The branch is conflict-free. - Map and module-boundary checks passed. Current-head Greptile is 5/5 with zero unresolved review threads. Reproduce the opt-in storage suites with `PAPERCLIP_LOG_TEST_S3_ENDPOINT` and a dedicated `PAPERCLIP_RUN_EVIDENCE_MIGRATION_DATABASE_URL` ending in `_test`. See `doc/run-evidence-storage.md` for operating limits, automatic migration, optional diagnostics and rollout qualification. ## Risks - Keep the existing per-stack bucket, prefix and vault key stable across replacements. Relocating that storage is a separate whole-instance operation. - This release automatically changes new log storage for existing S3-configured instances. Local-disk instances remain local. Canonical native source replay is qualified with a deterministic real Runner; actual remote execution and production-provider qualification remain rollout gates. Generic server-only diagnostics and optional raw trace tails without a surviving source can be incomplete after a crash. This does not establish full zero-downtime deployment. - Before deploying this release, qualify the actual S3 provider. It must enforce conditional writes and pass read, version, deletion, workload, and latency qualification. A capability probe rejects providers which ignore preconditions. Moto is emulator evidence only. - Dirty output is bounded and unconfirmed until S3 publication. Storage failure leaves persistence incomplete while task results and usage can settle. - Trace expiry is not yet represented by Cloud's external wake contract. Outstanding trace deadlines conservatively block sleep. - Automatic history copying requires the original source volume. Keep it until all retained resources pass verified import and clean-filesystem reads. Stop old binaries from creating new local-file runs. Missing or corrupt history remains blocked and visible in server logs. Rollback requires a compatible reader against the same external state. Ordinary object deletion does not erase retained historical object versions or backups. ## Model Used OpenAI Codex, `gpt-6.1-sol`, with reasoning, tool use, code execution, and browser verification. The runtime did not expose a context-window size. ## 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>	2026-10-30 15:17:35 -05:00
DottaandPaperclip	3b84c89885	fix(ci): use complete merge diffs and allow audited documentation (#18362 ) ## Thinking Path > - Paperclip manages AI agents and needs reliable checks for each contribution. > - CI selects affected suites and then affected Vitest files before allocating runners. > - Recent runs compared a tested merge against a stale event base. > - That included unrelated master changes and sometimes reached the compare API file cap. > - Ordinary documentation also forced every suite and invalidated test caches. > - This PR reads complete merge trees and exempts a small set of audited prose inputs. > - Tests retain conservative coverage when the diff or an input is uncertain. ## Linked Issues or Issue Description Refs #18348 and #18214. This is a follow-up to the merged affected-test selector. Related CI performance work: #16513 and #16500 address setup and suite execution. This PR changes diff collection and input classification. ## What Changed - Fetch the exact tested merge and its parents into a temporary bare repository. Read the complete tree diff against the actual first parent. Validate the second parent against the event PR head. Never execute PR code in the routing job. - Carry the immutable base, merge and PR-head identities into the plan. Validate the same complete diff again before file selection. - Use one prose policy across the planner, Vitest selector and task cache adapter. Exempt only `doc/DEVELOPING.md`, `doc/DATABASE.md`, and Markdown under `doc/plans/`. - Keep the uncached typecheck and CLI guidance guard for the first two documents. Keep policy checks for historical plans. Keep existing coverage for all other docs, runtime skills, fixtures and unknown inputs. - Extend candidate-workflow qualification to exercise mixed source and prose changes. ## Verification - Passed: 15 planner and Git routing tests, including a 353-file diff, stale base, rename, deletion, wrong parent and fetch-failure cases. - Passed: 83 routing, Vitest graph, exact selection, workflow and real Turbo cache checks. - Passed: `pnpm -r typecheck` and `pnpm build`. - Full local `pnpm test:run` was attempted and stopped after repeated embedded PostgreSQL startup failures in native-session and Muse tests. It did not pass or complete. The exact cause remains unverified. The changed files do not include those tests or their database setup. Linux CI results are recorded below. - Passed: real mixed Inbox/source/prose graph qualification selected 699/911 workspace test files, preserving the source-only selection. - Passed: both GitHub CI qualification jobs, including real mixed source/prose Vitest selection. Greptile reviewed commit `10ac6f5ec9` at 5/5 with no findings. - First full CI attempt: the [chat shard](https://github.com/paperclipai/paperclip/actions/runs/41111003419/job/124253342684) received a runner shutdown signal. The [Runner shard](https://github.com/paperclipai/paperclip/actions/runs/41111003419/job/124253341271) failed the unchanged Antigravity authentication success assertion. All 11 cases in that file passed when run directly. That Runner lane does not use the changed selector/cache path. The exact assertion-failure cause remains unverified. The chat shard passed on the one retry. The authentication assertion also passed on retry, but the same Runner shard failed a different unchanged test: `native-distribution-integrity.test.ts:242`, "retains spawned native bytes until the exact child exits", exceeded 5000ms. The [retry log](https://github.com/paperclipai/paperclip/actions/runs/41111003419/job/124259174201) preserves the failure. The Runner shard and required verify aggregate are still red; all other checks passed. All 33 native-distribution tests then passed in a direct local run. This shows recovery in isolation, not the cause of the Linux timeout. No further blind reruns were issued. - Replayed 15 real recent PR merge commits through a blob-filtered bare fetch. Nine needed a corrected base. The four API comparisons that returned 300 filenames became complete diffs of 3, 57, 66 and 54 files. The 3-file case (#18326) becomes eligible for graph selection. Most other samples still correctly use full CI because they include inputs outside this narrow prose policy. - Cache proof: prose edits preserve a product-test cache hit; changing runtime API documentation invalidates it. ## Risks - Prose exceptions must be removed or revised if product code starts reading those files. The allowlist is deliberately small. Runtime docs and skills remain covered. - A network or Git failure keeps the full-suite fallback. Unexpected merge topology also keeps full CI. Stack and force-full policies remain in place. - This does not claim an end-to-end speedup yet. Many mixed-content PRs still require full CI. The routing fetch reads only shallow commit/tree objects; it does not check out or execute PR files. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools and code execution. The exact served model ID and context-window size are not exposed to this session. ## 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 - [ ] 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>	2026-10-30 14:29:39 -05:00
DottaandPaperclip	8f822bfcf7	fix(cloud): persist configuration and load release-image packages (#18335 ) Land the approved Cloud configuration and release-image package stack. Includes the separately reviewed adapter settings (#18335), external adapters (#18333), bundled plugins (#18336), startup configuration (#18339), and migration/package checks (#18341). Includes the final image-owned loader and linked-dependency inventory corrections. Verified stack head: `462716170d`. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-30 19:21:33 +00:00
DottaandPaperclip	52e846f2f3	perf(ci): select affected Vitest files before allocating test runners (#18348 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its CI must catch regressions without running unrelated work on every pull request. > - The existing task planner selects package lanes, but each selected lane still runs all its test files. > - Vitest can find related imports, but that graph misses tests that read files or launch processes. > - This pull request combines the real Vitest graph with conservative dependency checks before CI allocates test runners. > - The result runs fewer test files and can allocate fewer jobs while retaining tests with unknown dependencies. ## Linked Issues or Issue Description Refs #18214. The repository and PR search found no duplicate file-selection implementation. What existing behavior does this improve? The general and serialized Vitest lanes in pull request CI. Current behavior An affected package schedules its complete test lane and its fixed shard count. Proposed behavior For source-only diffs, select related tests plus conservative filesystem, process, network and opaque consumers. Repartition those files within their existing lane owners. Keep the complete original plan when selection cannot be trusted. Reason and benefit Avoid unrelated test execution and allocate fewer runners when the selected workload fits fewer existing job budgets. Report file counts and job counts separately. Breaking changes No product or API changes. The set of PR test files and jobs changes for eligible diffs. Full CI and the kill switch retain the original coverage. ## What Changed - Add a separate selection job on the gate-approved test fleet. The metadata gate does not load PR code. - Inspect real Vitest/Vite dependency edges. Retain opaque consumers and unchanged downstream projects. Respect only complete local mock factories. Reject unknown setup dependencies and source mutations during dependency setup. - Declare `oxc-parser` directly for AST inspection. This exact version is already a transitive dependency in the checked-in lockfile; the direct declaration avoids relying on pnpm's internal dependency layout. - Produce a merge-SHA-bound manifest with exact lane ownership and duration-aware partitions. Preserve serialized execution, chat shards and native Runner ownership. - Execute exact Vitest test specifications. Positional substring filters cannot accidentally run a similarly named file from another shard. - Use the original matrix if selection fails or times out. Fail selected jobs if their published artifact is missing or invalid. - Save the uploaded artifact ID in the executable plan. Failed-job retries reuse that artifact even when GitHub increments the attempt number. - Hash selected assignments into Turbo cache inputs. A subset cannot satisfy a full run or another subset. - Add graph, workflow, real-runner and real-Turbo qualification. The regression fixture proves a filesystem contract fails even when raw Vitest selection misses it. - Document selection limits, audit artifacts and `CI_VITEST_SELECTION=off`. ## Verification - All 138 affected routing, sharding, workflow, manifest, real Vitest and real Turbo checks passed under Node 24 on the final implementation. Additional release workflow checks passed. Cases cover opaque setup, remocking, generated inputs, Node's builtin loader, artifact retries, and exact execution of similarly named files. - Repository-wide `pnpm -r typecheck` and `pnpm build` passed before the clean rebase onto current master. The full remote typecheck and build are required on the current head. - `actionlint` passed for both changed workflows. `git diff --check` passed. - The Linux qualification run passed and selected 699 of 911 workspace test files for an Inbox change. UI graph construction took 16.1 seconds. This still uses two jobs. Synthetic partition coverage proves a 15-of-120 selection uses two of twelve jobs without dropping or duplicating files. - Both selected workspace shards passed locally. After tightening execution to exact specifications, the real colliding UI test ran as exactly one file with two passing assertions; the real server auth middleware test ran as exactly one file with 28 passing assertions. - The server probe selected 1,158 of 1,260 general files and 161 of 163 serialized files for an auth middleware change. Those conservative selections retain 12 general and nine serialized jobs. The server's temporary-home setup exception is pinned to reviewed content hashes; changed setup fails closed. - Full `pnpm test:run` has not been run locally. The full PR test matrix is required because this change modifies global CI inputs. Final-head CI is pending at runner allocation, and both qualification jobs are queued. Other recent repository workflows are also queued. Superseded runs of this PR were cancelled; this PR remains in draft until the required checks execute. - Greptile reviewed final commit `31b484fc5b412da245cffb52a8ac8977228c5651` at 5/5 with no unresolved findings. The earlier qualification run passed; it does not replace checks on the final commit. ## Risks - Dependency analysis adds setup and graph time. Fewer files do not guarantee a shorter critical path. CI summaries expose the actual file and job counts. - Static dependency graphs cannot describe all runtime inputs. Unknown inputs retain tests or use the original plan. The pure-package allowlist requires conservative review. - The trusted workflow runs from master. This PR exercises the new selector in the qualification workflow; ordinary PR selection starts after merge. Set `CI_VITEST_SELECTION=off`, use `full-ci`, or select full/shadow mode to disable narrowing. - The lockfile remains managed by the existing repository actions and is not changed here. ## Model Used OpenAI Codex, based on GPT-6, with repository tools and code execution. The exact serving model ID and context window are not exposed in this session. ## 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 - [ ] 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>	2026-10-30 13:16:29 -05:00
Nicky LeachandClaude Opus 5.5	abc270ee4c	fix(runner): attest upstream releases and bind ACPX uniformly for every harness (#18325 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Native ACPX runs admit a provider only when its saved profile and `commandDigest` match the current profile exactly. > - For Copilot, Grok and Pi, `commandDigest` hashed dozens of Paperclip source files. Claude, Codex, Cursor and Antigravity hash only their upstream release. > - Any change to a bound source therefore advanced these profiles. #18212 alone moved Copilot from v88 to v91 and Grok from v15 to v19. Each bump reset in-flight sessions and added immutable identity fixtures (about 160 on master). > - #18237 added the provider pack `contractDigest`, which now guards Runner source compatibility at the pack boundary. > - This pull request changes the Copilot, Grok and Pi digests to upstream release attestations, as the other providers already use. > - It also binds the shared ACPX layer the same way for every ACPX harness: the profile's `acpxVersion` and the pack `contractDigest`, which now covers the Runner's ACPX patch. > - The benefit is that Runner source changes no longer reset these sessions or need new profile versions and fixtures. ## Linked Issues or Issue Description Refs #18237, #18212, #17972. What happened? A Runner change that touched a bound source file changed the Copilot, Grok or Pi `commandDigest`. The author had to advance the profile version, regenerate an identity fixture and keep every old fixture. On deploy, saved sessions for that provider failed the exact admission check and started fresh. Expected behavior A provider's `commandDigest` changes only when its upstream release changes: an upstream version, a platform closure, the ACPX patch or the Grok launcher. Runner source compatibility is the job of the pack `contractDigest`. Steps to reproduce 1. On master, change a comment in `src/drivers/acpx/runtime-host.ts`. 2. Run `node packages/paperclip-runner/scripts/grok-profile-identity.mjs --check`. 3. The check fails. The Grok profile must advance, and the next deploy resets Grok sessions. ## What Changed - Add `packages/paperclip-runner/scripts/acpx-release-attestations.mjs`. It computes the release attestation for each provider: - Copilot and Pi: a canonical-JSON hash of the profile version, upstream package versions and the platform closure pins (Pi also binds its Node version). - Grok: the SHA-256 of `launcher.cjs`. Admission already hashes these bytes. - The attestation binds no Paperclip source, shared ACPX layer, absolute path, pack manifest digest or install layout. - Bind the shared ACPX layer once for every ACPX harness (Claude, Codex, Copilot, Cursor, Grok, Pi, Antigravity): - Add the Runner's ACPX patch (`patches/acpx@<runner acpx version>.patch`) to the pack `contractDigest`. A patch change now retires older image packs for every harness. Other packages' ACPX patches are not read. A build context without the Runner's patch fails. - Remove the ACPX patch hash from Cursor's release declaration (`cursor-contract.json`) and advance Cursor once to profile 17. Copilot, Pi and Cursor no longer bind ACPX in their own digests, like Claude, Codex, Grok and Antigravity. - Saved inputs for every harness already must match the current `acpxVersion`. - Claude and Codex digests do not change. - `generate-acpx-profiles.mjs` writes these digests to `acpx-profiles.json`. `check:acpx-profiles` refuses a stale digest. - Move the Copilot closure pins to `copilot-closure-pins.ts`, so that the generator can import them. `copilot-installation.ts` re-exports them. - Advance each profile once and then freeze it: Copilot 92, Grok 20, Pi 37. A version change at the switch keeps the rollout on the same path as every earlier profile bump. - Replace the historical version lists in `profile-compatibility.ts` with a range. Every revision from 1 through the current one decodes. Claude and Codex still decode revisions 1 through 5. Launch and recovery admission still require the exact current profile and digest. - Delete: - `scripts/copilot-profile-identity.mjs`, `scripts/grok-profile-identity.mjs` and its test - the Grok launcher source stamp - 159 Copilot, Grok and Pi identity fixtures, including three unreferenced `copilot-mainline-v` fixtures. The Cursor fixtures stay. - Rewrite the affected tests as behaviour checks: - Each provider admits only the exact current profile. Every earlier version decodes and is refused at admission. - The last source-bound digests, and a changed digest at the current version, are refused by recovery and by the backend factory. - The Rust Pi descriptor test uses the generated profile instead of fixtures. - New `acpx-release-attestations.test.mjs`: a relocated copy of the inputs gives the same digests, each upstream input changes only its own providers, and the generator refreshes and checks the manifest. - Remove the fixture exceptions from `.dockerignore`. Add the attestation script and the generator to the Daytona image content inputs. - Update the Pi install probe and the Rust integration constant for the new Pi digest. - Update the docs to describe the current attestation model: `doc/grok-native-runner.md`, `doc/RUNNER-INTEGRATION-PLAYBOOK.md`, `doc/observability.md`, `packages/paperclip-runner/docs/durable-recovery.md`, and the Copilot, Pi and rich ACP architecture reports. Each report now opens with the current profile identity; earlier source-bound profiles remain as dated chronology. No doc references a deleted file. ## Verification - In `packages/paperclip-runner`: - `node --test scripts/acpx-release-attestations.test.mjs scripts/contracts/contract-fingerprints.test.mjs`: 19 tests pass, including a Runner ACPX patch edit that changes the contract digest, other patch edits (including `acpx@0.12.0` for `adapter-utils`) that do not, and a build context without the patch that fails. - `node scripts/generate-acpx-profiles.mjs --check` passes. - `vitest run src/drivers/acpx src/backends src/contracts`: 1647 tests pass, 9 skipped. - `tsc -p tsconfig.json --noEmit` passes. - From the repository root, `vitest run --config tests/runner-e2e/vitest.config.ts tests/runner-e2e/daytona-image.test.ts`: 11 tests pass. - In `server`, the 8 test files that use ACPX profiles, pack digests or `contractDigest`: 1617 tests pass. - Not run locally: the Rust tests and `cargo fmt`, because this machine has no Rust toolchain. CI runs them. - Before this change, a synthetic upgrade check built two Runner revisions that differ only in shared source. A Claude checkpoint saved under the first revision rebinds under the second, and a changed Claude `commandDigest` starts fresh. This confirms that the provider JSON has no other build-dependent field. ## Risks - One reset at rollout.* The Copilot, Grok, Pi and Cursor digests and versions change once. Saved sessions for these providers start fresh on their next run, as after any earlier profile bump. After this change, Runner source changes no longer cause this reset. - Lost "source changed, so requalify" signal. The old digest forced a new profile version when bound source changed. Nothing enforced requalification: Copilot was last qualified at v47. Pack-boundary contract changes are now caught by the pack `contractDigest`. - Image packs are retired once for every provider. Adding the ACPX patch changes the pack `contractDigest`, so the controller uploads its bundled pack (about 16 s per remote start) until images are refreshed. Claude and Codex sessions are not reset: their digests and versions do not change. - Grok launcher and closure pins. The Grok digest covers only the launcher bytes. Grok's runtime version is still checked separately at admission, as before. - Grok digest equals early Grok profiles. The launcher bytes have not changed since profile 1, so the new Grok digest equals the published profile 1 digest. The profile version still separates them: launch, recovery and the backend factory require profile 20. An image pack from that period has no `contractDigest`, so the pack gate refuses it. `remote-provider-pack-verification.test.ts` now covers this case. - Docker context checks run `generate-acpx-profiles.mjs --check`, which now imports `.ts` pin files through Node type stripping. `materialize-pi-distribution.mjs` already relies on this on Node 24. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with tool use (shell, file edits, local test runs). ## 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-30 09:10:50 -07:00
Nicky LeachandClaude Opus 5.5	fa760dbce4	fix(runner): reuse image packs only with matching contract digest (#18237 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Remote native runs use a provider pack. The controller reuses a protected pack from the sandbox image when the pack is compatible. > - #17749 gates this reuse on a hand-maintained interface revision in `provider-pack-contract.json`. > - Later changes altered the runner/pack boundary (#17922, #18188), but nobody bumped the revision. A stale Claude or Codex image pack can still be reused across a sidecar contract change. This is the failure class of #17972. > - A manual revision has a "forgot to bump" failure mode. Source-byte hashes change on every refactor, so they are too brittle. > - This pull request declares the sidecar `session.open` contract in its JSON schema and computes a contract digest from the JSON contracts and Rust shapes. > - Image-pack reuse now requires an equal digest. > - The benefit is that an incidental change keeps image packs reusable, and a real contract change retires them automatically. ## Linked Issues or Issue Description Refs #17749, #17972, #17922, #18188. What happened? The controller reused an image provider pack when `compatibility.acpx` and the selected agent's profile digest matched. For Claude and Codex, that profile digest binds only the upstream executable. The ACPX interface revision stayed at 1 after later sidecar contract changes. A pack built before those changes passed the reuse check. Expected behavior The controller reuses an image pack only when the pack uses the same runner/pack contracts as the controller's bundled pack. Comments, formatting and refactors do not change that result. Steps to reproduce 1. Build an image pack from a commit before a sidecar input change, such as a new `session.open` field. 2. Run a controller from a later commit that sends the new field, with the same interface revision and Claude version. 3. Before this fix, `verifyRemoteProviderPack` accepts the old image pack. ## What Changed - Declare the sidecar `session.open` parameter set as a closed `sessionOpenParams` definition in `acpx-sidecar.schema.json`. - `generate-acpx-sidecar-contract.mjs` now generates `GENERATED_ACPX_SIDECAR_OPEN_PARAMS` from it. - `parseOpenParams` uses the generated list instead of an inline `Set`. The accepted set is unchanged. - This is the surface of #17972. The schema is now its source of truth. - Declare the nested `session.open` contracts that the sidecar parses strictly: - `protocol/provider-schemas/runtime-context.schema.json` closes every runtime context object. `parseNativeRuntimeContext` uses the field lists that `scripts/generate-runtime-context-contract.mjs` generates from it. - The sidecar schema declares the closed `providerPolicy` object, and `parseProviderPolicy` uses its generated field list. - The accepted fields do not change. - Add `packages/paperclip-runner/scripts/contracts/contract-fingerprints.mjs`. It fingerprints these contracts: - the PRP and sidecar JSON schemas, with annotation text removed - the generated catalogs in `generated/` - the Rust serde shapes, `json!` payload keys, match literals and env keys in `runner-core/src`, without test-only modules - the reserved env key lists in `configured_environment.rs` - Read only the trees that every pack build context contains. Fail when a registered source is missing, so two build contexts cannot silently produce different digests. - Use only Node built-ins. The registry adds no dependency. - Write `contractDigest` as a top-level payload field in `build-provider-pack.mjs`. The manifest digest algorithm and the existing field layout do not change. - Require an equal `contractDigest` for image-pack reuse in `remote-provider-pack-verification.ts`. A pack without a digest is not reused. The controller uploads its bundled pack, as it does today for any incompatible pack. - Re-attest the source-hashed profiles, because this PR changes their bound sidecar sources: - Grok becomes profile 15 and now also binds the generated allowlist, so a Grok field change in the schema still invalidates the Grok identity. - Copilot becomes profile 88, and also binds the generated runtime context fields. - Earlier profiles stay decodable. - Add the registry script and `generated/` to the Daytona image content inputs. - Document the digest and the schema-first rule in `docker/daytona-runner/README.md` and `doc/DEVELOPING.md`. ## Verification - `node --test scripts/contracts/contract-fingerprints.test.mjs` (in `packages/paperclip-runner`): 4 tests pass. - These changes keep the digest: - schema description text - schema reformatting - renaming `parseOpenParams` - Rust comments, `#[serde(skip)]` fields and `#[cfg(test)]` modules - edits to the `#[path]` test module `tests/provider_api_validation.rs` - These changes alter the digest: - a new `session.open` schema field - a changed constraint on the `remainingWork[].description` property - a new reserved env key - a new sidecar env key - a new checkpoint field - A build context without a registered source fails. - `node --test test/acpx-sidecar-contract.test.mjs`: 13 tests pass. A new case rejects an unknown `session.open` parameter and accepts each declared parameter. - `node --test scripts/grok-profile-identity.test.mjs`: 4 tests pass. A change to the Grok field in the generated allowlist invalidates the Grok identity. - `generate-acpx-profiles.mjs --check`, `generate-acpx-sidecar-contract.mjs --check` and `generate-protocol-manifest.mjs --check` pass. - Runner vitest suites pass: 470 passed, 1 skipped. They cover the sidecar, sidecar input and protocol, Copilot and Pi installation, profile compatibility, native execution, recovery identity, the backend factory and the environment. - Server tests: pack verification, executor and artifact preparation pass (1,004 tests). - `tsc --noEmit` passes for `packages/paperclip-runner` and `server`. - `tests/runner-e2e/daytona-image.test.ts`: 10 of 11 tests pass. The failing test also fails on `master`. It expects a literal `profile-v19-identity.json` line in `.dockerignore`, which uses a `profile-v*` glob. - Not run locally: - A complete `build-provider-pack.mjs` run. The builder rejects the local Homebrew Node because it is not portable after relocation. - Rust tests and `acpx-controller-recovery.test.ts`, because `cargo` is not installed. - The full `pnpm -r typecheck`, `pnpm test:run` and `pnpm build`. ## Risks - Only JSON contracts and Rust shapes are part of the digest. The remaining TypeScript-only definitions are the `paperclip_finish` and `paperclip_block` tool schemas in `completion-result.ts` and the TypeScript env key lists. They are not covered until they move into a schema. The nested `expectedIdentity` and `tools` values ignore unknown fields, so a change there cannot cause a startup rejection. - A change there can let a stale image pack be reused. The sidecar then rejects the input with its strict parser error. - Today, Claude and Codex image packs have no contract check at all. - The digest covers all registered contracts for the whole pack. A contract change for one provider kind also retires image packs for the other. Each replacement costs about 16 s per remote start until the image is refreshed. - Existing image packs have no digest. After deploy, the controller uploads its bundled pack until the image is rebuilt. - The Grok and Copilot re-attestations start fresh sessions for those agents once after deploy, as each profile bump does today. - The Daytona image content ID formula changes, so the next image build does not reuse a cached image. > 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 Anthropic Claude Opus 5.5 (`claude-opus-5-5`) through Claude Code in the desktop app, with repository tools, shell execution and research subagents. The session does not expose the context window size. ## 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 - [ ] 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-29 22:55:11 -07:00
DottaandPaperclip	99ec767a42	Fix forced CI execution and align OpenCode shell fixture (#18230 ) Use one explicit Turbo cache mode for forced CI execution and preserve cache trust boundaries. Match OpenCode’s ignored stdin in the relocated Linux shell-hook fixture while retaining strict OOM and parent-isolation assertions. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-29 18:19:11 -05:00
DottaandPaperclip	f5dcc505c0	perf(ci): select affected suites and cache task results (#18214 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Pull request CI checks the server, UI, packages, Runner, and release paths. > - An ordinary PR starts 48 jobs even when its diff affects only a small part of the repository. > - Repeated pushes also repeat successful tests with unchanged inputs. > - This PR selects affected suites before runner allocation and caches deterministic task results with Turbo. > - Required checks validate the plan. Unknown inputs and failed comparisons keep full verification. > - The benefit is fewer runner jobs and less repeated work, with full post-merge verification retained. ## Linked Issues or Issue Description What existing behavior does this improve? The GitHub Actions PR workflow repeats unrelated suites for each push. Subsystem affected Cross-cutting CI routing, test execution, and required-check aggregation. Current behavior An ordinary UI component change starts the complete 48-job PR workflow. Existing dependency and compiler caches do not reuse successful test results. Proposed behavior A trusted planner reads the tested merge diff and task inputs. A UI component change such as `ui/src/components/Sidebar.tsx` selects 18 jobs, including build and browser coverage. Successful general, serialized, and standalone Rust tasks can reuse unchanged results across pushes in the same PR. Reason and benefit Reduce unrelated jobs and repeated test execution. The 48-to-18 comparison measures planned job count. Remote wall-clock savings have not yet been measured. Breaking changes No application API changes. Required `verify` and `e2e` names remain stable. `verify` also checks serialized suites and the canary dry run. ## What Changed - Added explicit task inputs and a pinned Turbo version. An execution adapter calls existing package scripts without adding script aliases. - Added trusted diff planning and dynamic matrices with complete fallback matrices. - Added PR-scoped task result caches. External-state and revision-stamped checks remain uncached. - Added and created the `full-ci` override label, plus repository modes `enabled`, `shadow`, and `full`. Forced and shadow runs bypass result caches. - Added candidate-workflow qualification, planner and aggregate tests, and a real Turbo cache fixture. - Kept the repository-wide CLI guidance guard in the uncached typecheck lane so UI-only diffs retain this security check. - Documented rollout controls, input maintenance, and local inspection commands. ## Verification - Passed 537 focused CI policy, routing, matrix, cache, and shard tests, plus 146 existing release workflow tests. - Passed actionlint for all four changed or added workflows and `git diff --check`. - Passed `pnpm -r typecheck` and `pnpm build` on the implementation base. - Checked real repository task plans for existing general-test and native Rust commands. A real server partition passed, then restored from cache: Turbo task time was 20.022 seconds for execution and 151 ms for the cache hit, excluding wrapper/setup overhead. - The real Turbo fixture exercises the execution adapter and proves source, argument, toolchain-scope, and environment invalidation, result restoration, and retry of failed tasks. - Stopped the serial local `pnpm test:run` after over 30 minutes in favor of the complete parallel GitHub suite. A local parallel database-lane attempt had PostgreSQL startup errors and timeouts. The direct migration fixture passed, then all 273 database tests passed with one local worker. This recovery does not establish the exact cause of the earlier startup failures. The full GitHub PR suite and candidate qualification passed on commit `0bf07ae071c9fe7903edc604d44b5a175727fed0`. Greptile is 5/5 with no unresolved review threads. - All 40 CLI guidance safety tests passed with the exact uncached workflow command. - Verified that master rulesets require only `ci / verify` and `ci / e2e`; both names remain unchanged. - Trusted workflows load from master. The added GitHub-hosted qualification workflow exercises this candidate planner before merge. ## Risks - Changes to global inputs, including task definitions and execution helpers, force execution and disable cache restore/save for the full PR diff. Missing a cross-package filesystem read could omit a suite. Inputs include known server reads of UI files and shared tests of UI assets. Unknown paths, malformed or truncated diffs, and definition download failures select all suites. - Task result reuse requires complete inputs. Keys include Git source files, scripts, resolved dependencies, environment, toolchain, checkout path, and unclassified source files. Generated build artifacts are excluded from input hashes. Registry smoke, browser, and revision-stamped tasks remain uncached. - Maintainers must update task inputs when suites start reading new paths. `shadow` reports selection while running all work. `full` and `full-ci` disable selection and result reuse. - The implementation becomes active after merge. Full post-merge verification remains unchanged. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository inspection, tool use, and code execution. The session does not expose a verifiable exact runtime model ID or context-window size. ## 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>	2026-10-29 16:56:28 -05:00
DottaandPaperclip	09c05c5505	feat(runner): provision pinned Google Antigravity native runtime (#18187 ) ## Thinking Path > - Paperclip manages agents and their work. > - Native Runner providers need verified executables before they can run. > - Google Antigravity ships a native ACP server and a helper executable. > - An archive hash alone does not verify the installed runtime or its child process cleanup. > - This pull request adds a pinned installer and a small, verified compatibility patch. > - Later pull requests add Runner execution, account setup, and the recorded user journey eval. ## Linked Issues or Issue Description Refs: #12503, #14938. Those pull requests use the legacy CLI adapter. This stack adds native Runner ACP support. Agent or provider Google Antigravity ACP 1.4.3. Why this adapter is useful Users need a reproducible runtime before they can select Antigravity for a Paperclip agent. How the agent is invoked The installer prepares the native ACP server and helper. This pull request does not enable task execution. Default execution remains closed pending qualification. ## What Changed - Pin the complete macOS ARM64 runtime closure. Keep other platforms as inventory only. - Verify archive entries, installed bytes, ownership, and cache layout. - Patch exact upstream code anchors for model admission, instruction loading, native process ownership, and per-call file tool completion. - Package a self-contained installer and expose `paperclipai runtime setup antigravity`. - Record candidate limitations and historical acceptance evidence. ## Verification - Runtime provisioning, packaging, metadata, and patch support tests: 62 passed. The separate exact pinned native patch run passed all 5 tests with no skips and no Google authentication. - CLI runtime setup tests: 5 passed. - Map contract check passed. Staged diff whitespace check passed. - The first test command ran before dependency installation and failed on missing esbuild. The same command passed after installation. - Current master has a stale lockfile. Dependencies were resolved locally with scripts disabled. The generated lockfile is excluded from this pull request. - Final head: required `ci / verify` and `ci / e2e` passed, and Greptile is 5/5 with both review threads resolved. The optional external Paperclip Review remains queued. Two original timing failures are retained; one failed-job rerun passed without source or deadline changes. ## Risks - The patch depends on exact upstream native code. A new upstream release must get a new verified closure. - Only macOS ARM64 has a complete verified runtime. Installation does not qualify authentication, task execution, or other platforms. - The installer downloads official Google assets when the verified cache is absent. ## Model Used OpenAI Codex (GPT-6). The host did not expose the exact model revision or context limit. The model used tools for code edits, test execution, and review. ## 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>	2026-10-29 13:25:54 -05:00
DottaandPaperclip	f1911a4c53	perf(skills): move repository packages out of Postgres (#18082 ) <!-- entire-trail-link-start --> https://entire.com/gh/paperclipai/-/trails/205/changes/paperclip/205 <!-- entire-trail-link-end --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agents receive selected company skills before each turn. > - Imported skills can need files from the whole source repository. > - The current path stores those files in Postgres and reads large JSON payloads during preparation. > - This pull request stores verified packages in the configured file or object store and keeps preparation queries small. > - It also converts old rows automatically and restores missing files from the exact saved commit. > - The result reduces database traffic while preserving skill versions and repository dependencies. ## Linked Issues or Issue Description What existing behavior does this improve? Company skill import, version storage, and preparation before agent turns. Current behavior Repository snapshot bodies live in JSONB. Skill preparation can read those bodies again even when the files already exist on disk. Historical packages and native assets also need a bounded cleanup path. Proposed behavior Store package archives and manifests through the existing storage service. Keep version identities, receipts, hashes, and recovery metadata in Postgres. Convert legacy rows after the stored package passes read-back verification. A missing package can use legacy bytes or its exact Git commit under current repository authorization. No separate data-migration command is required. Reason and benefit The warm path sends no repository bodies through SQL and reads no object bytes. Cleanup runs through the existing deadline coordinator. Current versions, active runs, explicit pins, and authored content retain their protection. Breaking changes The normal application schema upgrade is required. Single-version and skill-file responses keep their existing shape. Version lists, current-version summaries, and test-run version summaries now contain file names and kinds without file bodies. Diff and restore fetch selected versions through the existing single-version endpoint. Older server builds must not write after conversion unless they support the new package format. The storage override and rollback limits are documented in `doc/skill-package-storage.md`. Additional context Related work: #15731 preserves repository dependencies; #17923 changes version-cache scheduling; #18080 changes delivery to remote Codex homes. This change owns package persistence, acquisition, and expiry. It does not replace those delivery or scheduler changes. ## What Changed - Add company-scoped archive receipts, exact-commit recovery recipes, migration deadlines, and a durable object-deletion queue. - Add bounded archive upload, read-back verification, extraction, concurrent request coalescing, and verified local caches. - Convert old snapshots and versions automatically. Keep legacy bytes when verification fails. - Recover missing files through current source authorization and the original commit. Validate repository identity, file hashes, modes, and the aggregate hash. - Expire unused recoverable Git packages and native assets after 30 days. Preserve active pins and the durable copy of authored or unproven content. - Keep warm preparation queries metadata-only. Bound file digest caches and avoid repeated body hashing when file identities are unchanged. - Extend the existing storage contract with cancellation. Register package work with the existing coordinator. Optional conversion retries retain the original bytes and may wait for ingress without blocking sleep. - Add regression tests, operating guidance, a deep trace, benchmark receipts, and an optional maintenance command. ## Verification ### Final master integration and review repair — October 29, 2026 Current head: `a6065424249e763dfeac37161f1b52a9f25bd9b7`. Commit `f8bbdd3dbd` resolves the conflicts with master `76a796e964`; the final two commits repair the Apex deletion findings below. - Keep both package-maintenance and version-retention notifications in their write transactions. - Keep the shared run-pin predicate and master's controller-lease deadline metadata. Package expiry reads the updated protected-version result. - Preserve every master migration entry. Generate migration 0415 (`0415_zippy_zemo.sql`) after master's 0414. Its skill SQL is byte-for-byte unchanged from the previously tested idempotent migration. Retain only the five newest schema snapshots. Migration numbering and safety checks pass. - Repair failed file/folder deletion: preserve a complete temporary subtree until transaction commit, restore on upload or SQL failure, and restore callback failures before releasing the mutation lock. Both PostgreSQL regressions reproduced missing files before the fix and now pass. They cover binary data, executable permissions, empty folders, unlisted files, unchanged database/version rows, successful retry after upload-claim expiry, and historical reads. - Reconcile lost commit replies under the same advisory and row locks. Check the saved version and source identity before restoring. Keep committed deletions intact and preserve backups when the database outcome is unknown or a newer edit exists. Four real-PostgreSQL outcome tests pass; the prior code failed three of them. - Full workspace typecheck and production build pass on the final commit. All 204 focused PostgreSQL package/cache/retention/authoring and filesystem-boundary tests pass, with none skipped. - Apex review 18 passes 5/5, with zero new comments on the exact final head. All 34 review conversations are resolved. - [Final-head CI](https://github.com/paperclipai/paperclip/actions/runs/40914116508) completes successfully on attempt 2. The head has 55 successful checks, two neutral reports, two skipped checks, and a successful Snyk status. No checks are pending or failing. All eight browser shards pass. - Runner Vitest 2/2 timed out once in the unchanged ACPX controller-replacement fixture. The same job passed on the preceding commit. One unchanged CI retry passes all five ACPX recovery cases, 2,253 Runner package cases and 126 native server integration cases; their standard one and five skips remain. The initial timeout's root cause is not established. Local diagnosis also hit the fixture's eight-second session.open timeout with an authenticated Runner; no local Runner pass is claimed. - Both full local `pnpm test:run` attempts were stopped when Apex identified deletion defects and source repair became necessary; neither is claimed as a passing full local run. The final 204 focused tests, full workspace typecheck, and production build pass. Full-suite acceptance uses the final-head CI jobs. The superseded merge-head CI included runners terminated by shutdown signals; each source repair started a new full run. - Auto-merge is enabled for squash merge. The final head is conflict-free and all checks pass. GitHub's active master ruleset still requires a code-owner approval for the dependency files. The existing review requests are with `devinfoley`, `nickyleach`, and `forgottendev`; no policy bypass was used. - The earlier hosted stress and full native receipts below remain tied to `a2e597d800`; they are not relabeled as a deployment of this final integration. The earlier local PostgreSQL startup failure remains recorded below; PostgreSQL ran successfully for this integration verification. ### Full native skill execution — October 29, 2026 The full native-agent acceptance gap is closed on candidate `a2e597d800eb989d565780e7aa947d5368676444`. Two qualifying native turns used OpenAI API / `gpt-5.4-mini` in real Daytona sandboxes, on the same disposable hosted TEST tenant as the stress test. A follow-up on the same task consumed a newly saved skill version. The task text asked for the assigned skill workflow. It did not contain the proof nonce or expected receipt. The assigned authored skill contained a Python verifier and a random package-local nonce. The agent read the actual installed skill files and executed that verifier against the imported, automatically converted 1,360-file repository package. It checked the repository file count and reference/binary bytes, and directly executed the repository's executable probe. Independent verification matched the emitted JSON to the nonce and expected byte hashes. The agent persisted the same receipt as its task response; native finalization committed, workspace finalization succeeded, and task state became Done. \| Qualifying turn \| End-to-end run time \| Recorded skills.prepare \| Repository files \| Binary hex \| Shell receipt SHA-256 \| \|---\|---:\|---:\|---:\|---\|---\| \| Initial task \| 47.881 s \| 1822 ms \| 1360 \| `00ff07800a` \| `a1deb30dc095f2306c7aa9cc5ec396da12c68961cf5b809f4d7c20f7fc68493b` \| \| Corrected follow-up, new nonce/version \| 37.974 s \| 377 ms \| 1360 \| `00ff07800a` \| `dbcdc33fa1376b4edc136feae1cdf770560a73292467e93619efdda20e4282a7` \| Both successful shell receipts reported `probe: STRESS18082` and `assetSha256: e8ea7a2f15f7bb3b332a46adbef848465884c8996595aa234748befd544d1f3a`. Their proof nonces, selected version IDs and receipt hashes differed, and both ran on the same task. These are observed timings, not latency SLOs; they include real provider work. The service stress-test timings remain a separate measurement boundary. Earlier failures remain in the evidence: - The original five-minute Daytona allocation timeout never reached model execution. After normal owned-stack restore, its durable cleanup record was `expired` / `success`. The cause of that original allocation timeout remains unknown; a later success establishes recovery only. - Initial continuation setup used unsupported generic agent-update fields and returned HTTP 409 before dispatch. Setup was corrected to use the supported skill-assignment and versioned instruction commands. - The intervening completed native turn read repository bytes and ran the probe, but omitted the verifier JSON under the older test agent's overly-specific instruction file. Its strict receipt validator failed; it is not counted as a qualifying turn. Correcting the test agent's instruction file and sending an explicit task-scoped wake produced the qualifying follow-up above. - The pinned application's immutable rate card omits `gpt-5.4-mini`, so completed usage triggered the normal block-on-unpriced budget policy. Supported append-only accounting corrections estimated the three completed runs using the [official OpenAI model rate card](https://developers.openai.com/api/docs/models/gpt-5.4-mini): $0.75 input, $0.075 cached input, $4.50 output per million tokens, assuming standard processing. Estimates totaled 12.482655 cents. Original usage and missing-price records are preserved; the $1 hard stop and unpriced-usage guard stayed active. - Model shell attempts included a missing `xxd` command and incorrect guessed file paths. Those failed calls and subsequent successful actual verifier calls remain visible in complete event streams. No zero-tool-error claim is made. No product source changed during this continuation. The previously measured contention, cold-start and memory limits remain. The later merge resolution is covered by the separate integration checks above; these hosted receipts qualify their recorded candidate. ### Hosted stress test — October 29, 2026 Hosted acceptance: full native-agent execution and a changed-skill follow-up pass on the recorded hosted candidate. The final integration section above records the subsequent conflict resolution and its separate checks. Tested baseline `929e840595c8933ca485ac7a2e99413e1e11ca64` and this exact candidate sequentially on one disposable TEST tenant, with external Neon PostgreSQL and actual S3. The fixture contained 1,360 files / 22.4 MB / ten skills sharing one repository. Measurements cover deployed skill-preparation and native-context services in an adjacent diagnostic process, not a complete agent turn. The container had 24 vCPU / 24 GB. \| Warm workload \| Median before → after \| p95 before → after \| DB returned value bytes/preparation before → after \| \|---\|---:\|---:\|---:\| \| One skill, serial \| 1,060 → 125 ms \| 1,303 → 155 ms \| 22,610,389 → 1,771 \| \| One skill, four concurrent \| 4,415 → 297 ms \| 5,143 → 328 ms \| 22,610,389 → 1,771 \| \| Ten skills, serial \| 5,723 → 535 ms \| 6,057 → 600 ms \| 224,739,030 → 10,671 \| \| Ten skills, four concurrent \| 24,410 → 1,986 ms \| 24,833 → 2,221 ms \| 224,739,030 → 10,671 \| - Candidate warm preparation performed zero S3 GETs. Ordinary-pool queries fell from 16 to 9 for one skill and 61 to 9 for ten, excluding dedicated lock connections. DB numbers measure returned values before Drizzle decoding, not wire bytes. Baseline/candidate sample counts were 30/100, 32/100, 5/50 and 8/48 respectively; the small baseline ten-skill samples are comparative evidence, not SLO estimates. - Application-UID soak: 800 ten-skill preparations over 10.3 minutes, four workers paced by 2.5 seconds; zero failures, median 559 ms, p95 775 ms, p99 910 ms, zero warm S3 reads. All 726 accompanying health/company-list requests returned HTTP 200. Their end-to-end p95 was 569/502 ms, including network latency. The probe overlaps most of the soak. Soak DB-response capture was limited to its first 60 seconds. - Important remaining costs: an unpaced 16-way ten-skill burst had p95 8.32 seconds because company-level preparation serializes. Cold preparation took approximately 1.1–2.5 seconds for one skill and 7.4–10.0 seconds for ten. Ten-skill diagnostic RSS remained about 1.17 GiB (baseline 1.18 GiB), and the soak peaked at 1.35 GiB. A concurrent whole-container sample was 3.45 GB. This does not establish suitability for a small-memory host or eliminate per-entrypoint native asset duplication. - Upgrade without a manual data migration passed: legacy snapshot JSON shrank from 22,465,691 bytes to `[]`, with a stored package and zero pending conversions. - Recovery passed: sixteen concurrent cold requests coalesced into two S3 GETs; full bytes/binary/executable modes matched; same-size corruption repaired; an injected storage failure preserved warm access and failed cold access safely. A disabled public-Git source denied recovery, and after the actual five-minute backoff its exact SHA reconstructed all 229 files. Cross-company descriptor access was denied. Private-Git credential revocation was not tested. - Retention passed: reclaimed 27,754,496 allocated cache bytes, deleted an unreferenced package row and both objects, preserved aged authored history, and expired/reacquired reconstructible Git content. A version pinned by the failed native run was correctly retained. Only owned fixture timestamps were aged. - Browser UI passed: authored skill creation, saved edit surviving reload, version history, and restoration of earlier content. - Initial native attempt (superseded by the qualifying turns above): one real run failed at Daytona allocation after five minutes (`setup_failed`), before any model execution. Provider cleanup also reported failure. That attempt does not count as a passing native turn. Its receipt and all evidence remain preserved; its cleanup later recorded success after normal restoration. - Initial A/B commands ran as SSH root. Diagnostic-owned lock/cache permissions caused one setup HTTP 500 and the first UID-1000 soak to fail; exact fixture paths were repaired. The final soak, retention and recovery ran as application UID 1000. A fresh UID-1000 one-skill batch also passed (30 samples, median 116 ms, p95 321 ms, 1,771 DB value bytes/preparation). Earlier harness-export, SSH, npm provenance, backoff and UI-wait failures remain recorded alongside their successful retries. - Private evidence includes raw timings, assertions, HTTP probes, screenshots and failure/cleanup receipts. Initial failed-campaign cleanup suspended and retained the owned TEST tenant and released the shared QA account lease at 15:22:41 UTC. The tenant was subsequently resumed under its existing ownership for the native execution qualification above. Final cleanup completed at 15:53:09 UTC: the account lease is released and the tenant is suspended/retained under the original October 30, 12:24:52 UTC retention deadline. Its separate stack lease remains held; no active or pending-cleanup environment lease remained. The original retention window is deliberately preserved even after successful continuation. - Earlier hosted-tested head: `a2e597d800eb989d565780e7aa947d5368676444`, integrated with master `929e840595`. The earlier merge conflicts were resolved at this head. [Current-head CI](https://github.com/paperclipai/paperclip/actions/runs/40884087629) passed; all checks are complete with 55 successes, two neutral reports, two skips, and no failures. [Apex review 15](https://github.com/paperclipai/paperclip/pull/18082#issuecomment-6480257258) passed 5/5 with zero findings on this exact head. All review conversations are resolved. - Ten real-filesystem boundary cases and server typecheck pass locally for the security fix. Coverage includes cache roots, descendants, individual files, symlink aliases, recursive ancestors, a future concurrent cache fill, and allowed sibling directories. [Current-head private-project integration tests](https://github.com/paperclipai/paperclip/actions/runs/40884087629/job/123483306405) passed all 29 cases, including authorized and unauthorized imports of a cached private package. Full typecheck, build, server suites, all eight browser shards, and Runner checks passed in current-head CI. Local database tests could not run because PostgreSQL could not initialize; this limitation is recorded below. - The earlier generated migration preserved the newest five snapshots. The final integration renumbers its unchanged SQL to 0415. Migration safety/numbering checks pass. Its SQL is byte-for-byte identical to the previously verified idempotent skill migration; repeated application on this latest schema was blocked by the same local database startup failure. - The broader verification before the final migration-only rebase passed 1,025 package, lifecycle, remote-launch, native-session, and asset-retention tests, 52 focused UI tests, full workspace typecheck/build, token gates, and map checks. The linked complete CI run passed before the latest focused fixes. - A disposable MinIO instance passed multipart upload, verified read-back, and cold restoration of an 18 MB archive. - Twenty warm samples with a synthetic 1,349-file, 22.8 MB repository retained five metadata queries and zero object reads. Median preparation was 256 ms for one selected skill and 691 ms for ten, with 5 ms emulated network delay each way. These are local measurements, not production latency guarantees. - No production instance was changed. Earlier verification failures and their disposition are retained below. <details> <summary>Earlier failures, review findings, fixes, and rerun evidence</summary> - The first CI pass found a stale inventory-span expectation and a missing repository-read span. Both are fixed; all three observability tests pass. One browser test copied page text into its YAML parser after reload; its first unchanged-head retry passed, but the race recurred after rebasing. The test now waits for the renamed URL and completed reload before copying the editor, retaining its original assertions. The earlier full local suite did not complete cleanly: it reported setup timeouts and assertions, while isolated relevant reruns passed. The complete current-head CI run closes that broad verification gap. No production instance was changed. - The first Apex review scored 2/5 and identified six issues. The fixes protect authored history even when it shares an in-flight Git upload, recheck upload expiry during orphan deletion, bound failed-upload cleanup, retain per-version kind/encoding metadata, add sanitized failure diagnostics, and correct the migration guide. The final focused run passes all 140 tests; the preceding eight-file run passed all 149 tests, including local storage and S3 diagnostics. Server typecheck and migration safety/numbering checks pass after the fixes. The second Apex review scored 1/5 and found unbounded maintenance storage calls and mismatched package/Git batch limits. Those are fixed with a 30-second cancellable cleanup deadline, shared 100 MiB/10,000-file scanner and storage limits, and bounded Git read batches. The proposed manual lockfile edit was rejected with evidence of the enforced CI-owned lockfile policy. All 19 storage/recovery unit tests and server typechecking pass. The new database-backed cleanup/conversion tests were locally skipped because the host exhausted its PostgreSQL semaphore capacity (confirmed directly by initdb). That gap is closed by current-head CI: [package-store tests](https://github.com/paperclipai/paperclip/actions/runs/40771320775/job/123109300889) pass all 18 cases and [package-worker tests](https://github.com/paperclipai/paperclip/actions/runs/40771320775/job/123109301157) pass all 7, with no skips in either suite. The corrected YAML browser shard passes. A separate planning-fixture test failed its cleanup DELETE with an activity-log foreign key violation after its behavior assertions passed; its one unchanged-head retry passed. The third Apex review scored 1/5 and identified a one-slot pool deadlock, projected path limits, cleanup holding the preparation lock during archive reads, and a publication/expiry race. These are fixed with transaction-local reads, prefix-aware bounds, isolated verification, and shared package row locks with a publication grace. The separate Paperclip review also found stale historical inspection, eager history downloads, and conversion retries blocking sleep. Those are fixed. Local PostgreSQL capacity recovered: the new database regressions ran, including the one-slot fork, paused storage during a warm turn, and a locked publication during expiry. The expanded run passed 144/145 tests; its remaining assertion still expected file bodies from the version list and was updated to fetch the selected version. The corrected company-skill suite passes all 81 tests, and the final package/projection run passes all 27. All 52 focused UI tests pass after updating their query-provider fixtures; the first UI run exposed a fixture remount, and the follow-up exposed an editing syntax error, both corrected. Full workspace typecheck and build, token gates, and map checks pass. The sandbox initially blocked the build tool’s local IPC socket; the authorized build rerun passed. Master then claimed migration 0401. The branch is rebased on `f8226b0515`, the unchanged SQL is regenerated as 0402, and repeated application passed twice on the combined schema. Post-rebase workspace typecheck passes. All 1,025 package, lifecycle, remote-launch, native-session, and asset-retention tests pass on the combined head. All CI checks passed for head 9d80a3b52d. The fourth Apex review scored 3/5 and found a save/edit lock-order cycle, a retry retaining an uncommitted source ID in its recovery recipe, and a summary read racing conversion. Commit b7d9237c6a fixes all three. The new concurrency and retry tests pass within all 61 package/source tests, and server typecheck passes. Master then claimed migration 0402. The branch is now rebased on `65fa1cd617` and the unchanged SQL is regenerated as 0403. All 68 package, source, and worker regressions, server typecheck, migration safety/numbering, and repeated migration application pass on current head `62553671a0`. Subsequent verification and review outcomes are recorded below. - The fifth Apex review scored 4/5 and found cached version reads unnecessarily depending on object storage and conversion reads missing the coordinator cancellation signal. Commit `1eb90d80be` fixes both: cached reads verify bytes without the preparation lock; manifest and archive reads carry cancellation through conversion. The first focused run passed 70/71 tests, including all three new cases, but the existing diagnostic test observed no warning. Its fixture now sets an explicitly expired migration deadline; the final worker suite passes all nine cases. Server typecheck passes. - The sixth Apex review scored 4/5 with one finding: concurrent cached inventories were unbounded. Commit `4b7589e14c` gives cached inventories and previews a two-reader/32-waiter limit independent of cold storage. The first expanded pressure test observed a third reader before the preview path had the same bound; both paths now share the local limit. All 73 focused cases pass, followed by all 29 package cases after the final overload adjustment; server typecheck passes. The separate Paperclip review found no must-fix or should-fix issues. Its optional suggestion to persist durability verification was considered: cleanup intentionally verifies current external bytes before discarding the last local authored copy, and the missing-object regression requires that check. Shared-package eviction happens on cold fills with at most two attempts and a ten-second budget. - The seventh Apex review reached 5/5 with one remaining P2: timeout-bearing manifest reads bypassed request coalescing. The security review also found repeated archive acquisition after a cold administrative read. Commit `79a80a39d2` shares manifest loads with per-caller cancellation and cancels the underlying work when the last caller leaves; coalesces identical cold version/file requests; and publishes verified restored packages into the shared cache. Publication uses a short nonblocking lock, while eviction verification runs outside it. The first expanded run passed 73/74 tests and exposed a missing originating DB for cache publication inside read-only inspection; transaction readers now pass that owner explicitly, keeping metadata on the transaction. The corrected run passed 75/75. A final eviction test initially expected the shared package to remain after only its separate runtime projection was reused; it now explicitly accesses the shared package during verification. All 32 final package tests pass, including independent caller cancellation, one acquisition across concurrent/repeated reads, and warm preparation during stalled eviction verification. Server typecheck passes. - The eighth Apex review scored 4/5 with one finding: decoded cold inventories outlived the storage semaphore while waiting for cleanup. Commit `9d7921d1ec` adds a separate two-response/32-waiter lifetime bound held through cleanup, preserving the independent warm-read queue and forwarding cancellation through eviction verification. The new regression pauses cleanup after two responses decode, verifies a third archive stays queued, and completes warm preparation before releasing cleanup. All 77 package/source/worker cases and server typecheck pass. On the preceding head, serialized server shard 6/9 was interrupted with “The operation was canceled” after 57 seconds of tests; the log contains no failing assertion. Fresh latest-head CI reruns that shard along with the other gates. - The ninth Apex review scored 4/5 with one P1: cold responses could own both permits while waiting on a one-slot ordinary database pool held by a queued transaction reader. Commit `a94f0e409f` reads caller-scoped metadata before admission and isolates all acquisition/cleanup SQL on a private connection. The new real-PostgreSQL regression reproduces the deadlock against the previous head and passes with the fix; all 78 focused cases and server typecheck pass. The previous CI run completed with 54 successful checks, including both formerly interrupted/stuck serialized shards. - The tenth Apex review scored 4/5 with one P1: preloading legacy bodies before admission could retain many full repositories in queued requests. Commit `276e353a37` removes that preload and also bounds legacy manifest derivation/fallback, using private connections inside the I/O slot. All 80 focused tests pass; the final synchronized package suite passes all 36 tests and server typecheck passes. - Apex review 11 returned 5/5 with zero comments on `276e353a37`. While it ran, master `8bc051245f` added migration 0403, creating a metadata conflict. Merge commit `e1783764d9` integrates master and generates 0404_clumsy_leo.sql; its skill SQL is byte-for-byte identical to the previously verified migration. The combined schema passes migration safety/numbering, repeated SQL application twice, all 80 focused PostgreSQL tests, full workspace typecheck, and full build. The preceding `a94f0e409f` CI run was superseded and cancelled while its final runner job was active; no old-head success is claimed for that run. - Final acceptance: Apex review 12 returned 5/5 with zero comments on `e1783764d9`. All 28 review threads are resolved. The final head has 55 successful checks, two neutral reports, two skipped checks, and no pending or failing checks; the PR workflow completed successfully. Superseded run 40789121902 was cancelled to free its workflow slot for the final head; normal cancellation did not finish promptly, so force cancellation completed it. - October 29 conflict resolution (`867c00673b`): master `929e840595` added installed-selection reuse and bundled relocation, routine cleanup notifications, a hardened YAML copy helper, and migrations through 0413. The merge retains those behaviors together with package read scoping and the public-selection fast path; restricted selections still reauthorize and the full row read rechecks scope. Generated migration 0414 retains the existing SQL unchanged. Workspace typecheck/build and migration checks pass. Local database verification is unavailable: initdb reports semget / “could not create semaphores: No space left on device”; all 168 cases skipped, and repeated migration application failed at startup. Docker returned HTTP 500 during container creation, so no Docker test pass is claimed. Current-head CI must close this gap. - Apex review 14 scored 3/5 with one P1: a local import could copy cached private package files into a company-wide skill. Commit `a2e597d800` rejects cache trees and ancestors through a canonical filesystem boundary, including aliases and ancestors checked before a concurrent fill. Ten local filesystem tests and server typecheck pass. The existing private-project integration case now rejects package-cache imports for both authorized and unauthorized users. The preceding merge commit’s complete CI run passed, and logs confirm all 168 locally skipped cases executed successfully: package store 36, sources 35, package worker 9, runtime selection 4, observability 3, authoring 81. - Apex review 15 returned 5/5 with zero new findings on `a2e597d800`. The separate Paperclip review found no must-fix or should-fix issues. Its optional suggestions were considered: unexpected filesystem cleanup failures remain visible, the durable marker cannot replace checking that bytes still exist before deleting a last local authored copy, and administrative history batching remains outside the pre-turn optimization. The cache-path literal centralization suggestion is also optional; the current producer and guard use the same directory, covered by the new integration regression. All review conversations are resolved. - Earlier October 29 CI/Apex acceptance: `a2e597d800` was mergeable at that check, Apex review 15 passed 5/5 with zero findings, and all review conversations were resolved. The hosted verification above records the later acceptance limits and renewed conflicts. Workflow 40884087629 completed successfully, with 55 successful checks, two neutral reports, two skips, and no pending or failed checks. The project-skill-sources job log confirms all 29 cases ran and passed, closing the latest integration gap. The preceding merge workflow also confirmed all 168 focused database cases ran and passed. No local PostgreSQL or Docker pass is claimed. </details> ## Risks - First use after eviction can require storage or Git access. Revoked grants, removed sources, and unreachable commits can prevent reconstruction. Recovery never substitutes a newer commit. - Historical packages without a proven recipe keep durable bytes. Cleanup favors retention when a run pin cannot be interpreted safely. - New uploads and conversion use bounded work and persisted retries. Large initial conversions still add temporary storage and database load. - Optional cleanup can wait until the next server wake. Supported notifications assume one owning server process. - Per-entrypoint native tree duplication and cold preparation cost remain. The final ten-skill cold sample took 47.6 seconds on the shared host. - Generic authored edits can still hold an existing edit transaction while a package uploads. - Explicit file/folder deletion uses temporary disk space for rollback. An uncertain commit with a changed skill or unavailable database retains that backup and logs its location for recovery. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools, code execution, and tests. The exact served model ID and context window are not exposed in this session. ## 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>	2026-10-29 12:19:37 -05:00
DottaandPaperclip	60b8089a44	fix(runner): trust managed Cloud sandbox images (#18066 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Cloud selects and updates the sandbox image used by its agents. > - Runner admission also required saved qualification for the exact snapshot and configuration. > - An image update left the old record stale and stopped work before runtime startup. > - This pull request trusts the image selected by Cloud and uses the real runtime startup check. > - Agents can continue after an image update without an operator running a separate qualification test. ## Linked Issues or Issue Description What happened? A managed Cloud image update could cause `sandbox_snapshot_qualification_required` before provider work began. Runner discovery also fell back to Legacy when saved platform qualification was absent. The agent Test action could require a separate qualification request even when discovery already offered Paperclip Runner. Expected behavior A managed Cloud image can start without a saved qualification record. Runtime startup and the handshake report actual compatibility failures. Custom images keep their existing qualification rules. Steps to reproduce 1. Use Paperclip Runner on a Paperclip-managed Cloud sandbox. 2. Save qualification for its current snapshot. 3. Update the platform-selected snapshot and leave the old record in place. 4. Start a task. Before this fix, admission rejects the stale record before starting the provider. Related work: Refs #17445, Refs #17724, Refs #17448. These changes cover saved-computer qualification and setup tests. This fix removes the qualification prerequisite only for managed Cloud images. ## What Changed - Use one managed-image policy in runner selection and lease admission. Require the active Cloud configuration to provision the provider. Active captured custom images are excluded. - Use the current Cloud image and ignore missing, stale, revoked or valid saved qualification records for that image. - Reuse the existing provisioned-runner selection path. Keep adapter availability checks and the Legacy choice for managed sandboxes. - Read custom-image metadata directly during discovery without resolving provider credentials. - Use the existing template-matching rule for captured images. Ignore outdated captures, preserve qualification for matching custom captures, and fall back to Legacy discovery for malformed saved capture config. - Skip the separate qualification request when discovery already offers Paperclip Runner as the default. Test checks the actual runtime. - Add regressions for image updates, provider failures, custom images, self-hosted environments and company access. Update the development and verification guides. ## Verification - Before the fix, managed-image discovery regressions returned Legacy, and the rendered Test action called the separate qualification endpoint. - The original runtime source fails four of the five managed-image regression cases. The fixed runtime passes all five, including provider startup error propagation. The baseline check uses the original module source through a temporary Vitest transform and the same database-backed tests. - All 603 focused tests pass: 231 runner selection, 185 environment runtime, 10 snapshot qualification, 168 rendered agent form and nine form source controls. Discovery controls cover unavailable credentials, stale managed markers without an active provisioner, outdated captures, matching custom captures and malformed saved config. The outdated-capture regression fails before the fix and passes afterward. - `node scripts/check-maps.mjs` and `pnpm check:token-gates` pass. - Full `pnpm -r typecheck` and `pnpm build` pass. All five focused files passed together on `8275bbe72bb4d91fb3a02fb0658f0846b2abc966` (`codex/simplify-managed-runner-readiness`, Node 24.19.0, macOS ARM64). - The full local `pnpm test:run` suite is still in progress. Hosted CI is waiting at `ci / gate / Select trusted runner`; the separate `review` workflow is queued. Greptile is 5/5 on the current head, and both review threads are resolved. This PR is not yet verified by full CI. - Live fixed-source Daytona acceptance is not verified. This workspace has no Daytona API key or image configuration. The earlier deployed recovery is not evidence for this source change. ## Risks - Managed Cloud now trusts its selected image. A bad image can fail at real runtime startup instead of a saved qualification gate. - Company access, credentials, runtime integrity and handshake checks still apply. Self-hosted sandboxes, custom environments and active captured custom images keep their qualification and immutable snapshot binding. - No schema change or data migration is required. Existing qualification records can remain in place. ## Model Used - OpenAI Codex, GPT-6 family, with reasoning, tool use and code execution. The exact model ID and context window are not exposed in this session. ## 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 - [ ] 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>	2026-10-28 14:39:26 -05:00
Devin Foley devinfoley Claude Opus 5.5 Paperclip Amy Dotta	d30c8f42b8	feat(ui): keep writes durable through temporary disconnects (#17960 ) <!-- entire-trail-link-start --> https://entire.com/gh/paperclipai/-/trails/123/changes/paperclip/123 <!-- entire-trail-link-end --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - People save tasks, write documents, make decisions and send board messages. > - A disconnect can hide a response after the server accepts a write. > - Recovery must keep the original account, task and request key. > - The merged connection foundation in #15754 handles reads and shared outage state. > - This change adds bounded write recovery and explicit actions when recovery stops. ## Linked Issues or Issue Description What happened? Temporary failures could lose edits, report accepted writes as failures, or require people to copy and send input again. A retry could target a newly selected task or account. Restoring attachments could create a second task. Expected behavior Keep the draft, its owner and its target. Retry only operations with a server contract that prevents duplicate writes. Verify uncertain results. Show conflicts and permanent failures, with an explicit resend or cancel action. Steps to reproduce 1. Save a task title during an outage, then open another task before recovery. 2. Restore a task creation that needs files, selecting those files in another order. 3. Lose a document or decision response, then interrupt the verification read. 4. Switch accounts while a create, upload or connected-channel publication is pending. 5. Type and erase a new-task draft before the first account lookup completes, then reopen it. This PR carries the write layer from #15769 and its review fixes. It targets master after #15754 merged. Related test cleanup #16952 already covers the unchanged copy-link toast test; this PR does not duplicate that work. ## What Changed - Add bounded autosave and submit jobs for supported writes, with pending, conflict and manual retry states. Retain admitted autosaves after navigation and preserve newer task revisions. - Keep each job with its original account, task and operation. First account resolution adopts admitted startup work; a later account change cancels old work. Remount inline and document editors when their owner or document subject changes. - Preserve task-creation keys and immutable request snapshots through file reattachment. Restore generated document keys before comparing reselected files. Reject changed requests instead of creating a second task. - Check the original account scope before creates and each upload. Save successful upload receipts before stopping on an account change. Identify attachments by content digest and metadata. - Verify uncertain document and decision results. Replay only plain, keyed comments automatically; combined reassignment, reopen and run-setting changes require receipt reconciliation or cancel. Settle each request once when a receipt races its retry. - Scope drafts and connected-channel publication reads to their owner. Keep unowned older records unread and unreplayed, with an explicit confirmed discard action after Activity inspection. Preserve typing through the first session lookup, keep erased text erased, and report browser persistence only when storage succeeds. - Wait for the first account lookup before sending startup status changes or decisions. Retry failed required lookups with a fixed limit and surface exhaustion to the original action. Preserve uncertain comment keys on account cancellation. Check the account generation before a comment retry calls its sender and again immediately before POST after asynchronous preparation. Retire only that request’s optimistic echo on completion. - Return an ordinary comment’s accepted same-company, same-task, same-user receipt before workspace reopening, task status changes or wakeups. Reused keys with changed text still conflict. Complete reference and activity records through the same finalizer for initial sends and accepted retries. It locks the task before its comment, matching task and company deletion, comment removal and tombstoning, rejects removed or tombstoned comments, repairs references and inserts a missing activity record in one transaction, and publishes after commit. - Remove reader-only record and comment-body size caps so accepted browser writes remain readable, including JSON-escaped comment requests in local and session storage. Update four existing Storybook fixtures to use owned draft keys. - Document the write contracts and add regression and real browser recovery coverage. - Add the exact reviewed-save recovery regression for both composer implementations and reloads. Align receipt completion, both comment deletion methods and company deletion with task deletion by locking tasks first. Cover real task and company deletion races. ## Verification - The exact reviewed-unknown-save regression fails in all four cases on original commit `1ed0af4186`. It passes with this PR for both composers, before and after reload. Cancel keeps the text and uploaded receipt. The retained draft sends, and the next message also sends. Run `pnpm exec vitest run --project @paperclipai/ui ui/src/components/composer-recovery.test.tsx`. - The new real PostgreSQL task-deletion race fails with SQLSTATE `40P01` on parent commit `f3253a00c4`. The company-deletion race also fails with `40P01` on `e8cf0e02dd`. All six receipt tests pass after the final lock-order fixes. They cover company deletion, task deletion, comment removal, tombstoning, concurrent cross-task references and interrupted reference repair. Run `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/issue-comment-receipt-postgres.test.ts`. - The full UI run passed 9,656 of 9,659 tests across 816 files. Three cases failed under that run: two large-tree timeouts and one plugin-panel assertion. All 67 tests in those two files passed in an isolated rerun. These failures remain recorded; this does not claim a clean full UI run. - `pnpm -r typecheck`, `pnpm build`, token gates and map checks pass on the final change. The local full repository test command was started, then stopped when the delivery moved to this existing PR. Fresh PR CI must provide the full-suite gate. - A local Storybook walkthrough used the real rich editor. Cancel kept the restored text, Send cleared it after the simulated save, and a new draft enabled Send again. Storybook simulates submission; it is not staging acceptance. - Earlier verification on `f3253a00c4` recorded five browser journeys for title saves, cached-task offline recovery, startup recovery, accepted comment replay and session lookup failure. Those results remain prior-head evidence. No new staging deployment is claimed. - On `e8cf0e02dd`, all CI checks passed after one browser-shard rerun. Its first failure copied page text instead of YAML in an unrelated agent-configuration test. On final commit `35131d4380`, Greptile is 5/5 with no unresolved review threads. The first CI attempt has two failures outside this diff: runner close-attachment suspension and scheduled-retry teardown. The scheduled-retry file passes all 14 tests in isolation; the isolated runner test still fails locally. The single standard CI rerun passed both jobs, and the aggregate verification gate passed. All CI checks are green on `35131d4380`; Apex is 5/5 on that same commit with no unresolved findings. ## Risks - Automatic replay requires server duplicate prevention or result verification. Uncertain combined mutations require receipt observation or cancel and a fresh intentional send. - Old unowned form drafts remain stored but are not assigned to an account. Unowned channel records can be retired after Activity inspection; this never cancels an accepted remote update. - Browser storage and hashing can be unavailable. Storage failure is reported honestly. Without a digest, replay can duplicate an upload rather than silently drop a selected file. - Detached autosaves remain bounded and check account ownership on each attempt. Conflicts or exhaustion retain the draft for explicit recovery. - No schema, credential or agent permission change is included. This PR does not claim staging deployment or original-task acceptance. ## Model Used Anthropic Claude Opus 5.5 (`claude-opus-5-5`) produced the original implementation with tool use. OpenAI Codex, GPT-6 family, assisted with restoration, integration, verification and review fixes. This Codex session does not expose its exact serving model ID or context window size. ## 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Amy (Opus) <claude@users.noreply.github.com> Co-authored-by: Dotta <bippadotta@protonmail.com>	2026-10-28 10:52:06 -07:00
DottaandPaperclip	c08da3e0a7	perf(server): narrow skill list reconciliation reads (#18023 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The skill library lists current company skills and their agent attachments. > - Each list request also reconciles bundled skills, folders, and local files. > - These reads return full agent records and large metadata that their callers do not use. > - Conditional requests do this work before they return an unchanged response. > - This pull request selects the fields each caller needs and avoids unused folder lookups. > - The result is less database transfer and fewer round trips while reconciliation stays current. ## Linked Issues or Issue Description Refs #17941. That change reuses bundled categories within an import. This change removes other repeated work in the same list path. What happened? Warm skill-list requests still made 119 SQL calls in a local HTTP fixture. The folder pass returned full skill metadata. The local-source pass also returned remote skills. Attachment counts loaded full agent configurations and monthly spend. Bundled reconciliation resolved folder paths that its release check did not use. Expected behavior The list must preserve its current result, attachment counts, access rules, local-file reconciliation, and bundled release checks. Internal reads should return only the data their callers need. Steps to reproduce 1. Use a company with many remote skills and agents with large saved configurations. 2. Read its skill list, then repeat the read with its ETag. 3. Measure the queries and response values before the server returns `200` or `304`. 4. Run `pnpm --filter @paperclipai/server exec tsx scripts/benchmark-skill-list.ts --samples=5 --network-delay-ms=3.5` for a synthetic reproduction. Paperclip version or commit Baseline service: `e1ba77f06771a27114b3999004b0ca5e3c172dd4`. The branch is based on current master. The paired mode changes only the skill-service module; both versions use the same imported helpers. Deployment mode Built from source. Local HTTP server and disposable PostgreSQL 17. No hosted deployment is part of this PR's local proof. ## What Changed - Read only the desired-skill selections of nonterminated company agents for attachment counts. Resolve each agent's references once against the full visible skill list. Preserve IDs, keys, aliases, duplicate handling, and ambiguous slugs. - Read only `sourceKind` from metadata for bundled folder classification. - Limit local-source reconciliation to local-path rows. - Skip folder-path enrichment only for bundled reconciliation. Normal imports and list responses keep their folder paths. - Add real-database byte regressions and a local HTTP benchmark. The benchmark can alternate the old and new services against one database, actor, and process. It checks complete response equality and conditional responses. The company-skill service owns these reads. The query predicates and freshness checks remain at their existing owners. This change adds no cache, schema change, or new background work. ## Verification - The attachment byte regression failed before the fix: 601,418 captured response-value bytes exceeded its 2,000-byte bound. The same case passed after the fix. It checks fresh configuration edits, IDs and keys, duplicate aliases, ambiguous slugs, paused agents, terminated agents, and company scope. - 111 focused service and authorization tests passed against isolated real PostgreSQL 17 databases. They include full result equality, retained stored Markdown and metadata, local-file updates, release checks, project visibility, and import authorization. - The default embedded PostgreSQL probe skipped the first local attempt on this Mac. The completed run used a local-only bootstrap adapter for disposable databases. Queries, migrations, services, authorization, and filesystem work used their real implementations. The adapter is not part of this PR. - In repeated synthetic HTTP byte runs, calls fell from 119 to 98 per request. Result-value bytes fell from about 7.75 MB to 1.64 MB per request, about 79%. These values are measured before Drizzle decoding. They exclude protocol framing and do not measure provider billing. - A separate-process run without the byte observer did not show a latency gain. The paired experiment removes that comparison gap: it alternates both services against the same database and checks identical complete responses. On final commit `3076fe1402085f7286ff58e642d7caca892a5f80`, five observer-free pairs had median times of 2.582 s before and 1.850 s after (28.3% lower). The candidate was faster in all five pairs. Its range was 1.802–2.199 s; the baseline range was 2.327–2.725 s. Every normal response had the same complete body hash, and both versions returned the expected unchanged conditional responses. These are local service/HTTP timings with synthetic data and 3.5 ms delay per network direction. They are not hosted acceptance. - Final-head workspace typecheck and build passed. The full local test command did not complete because embedded PostgreSQL bootstrap failed on this Mac; I stopped that owned runner after 16 native-runtime cases failed. All 16 cases then passed when rerun alone against disposable PostgreSQL 17 using their existing external-database path. The 111 focused PostgreSQL 17 tests above also completed successfully. This does not constitute a completed full local suite; all current-head remote CI gates passed (55 successful checks and 2 skipped). Module-boundary and whitespace checks pass. An initial nested package command used the global pnpm; subsequent commands were pinned to pnpm 9.15.4. - The first canary dry run failed while installing an unrelated standalone package: npm returned 404 for the newly published Rollup 4.66.0 tarball. The exact download subsequently returned HTTP 200. The one retry passed without code changes. - Benchmark commands: add `--capture-values=false` for observer-free timings. Add `--baseline-ref=e1ba77f06771a27114b3999004b0ca5e3c172dd4 --capture-values=false` for paired service acceptance. The normal mode uses the production router. The paired mode uses equivalent default-list HTTP handlers and a synthetic authenticated board actor; it does not test login. ## Risks The SQL selection must stay in sync if the desired-skill format or folder classifier needs new fields. Existing parsing and reference resolution still interpret the selected data. The synthetic fixture has large unused payloads. It proves the mechanism and preserves required content. Its percentage is not a projection of whole-instance transfer or billed savings. Hosted latency still needs verification after merge and deployment. ## Model Used OpenAI GPT-6 through Codex, with repository inspection, shell execution, real PostgreSQL, and local HTTP testing. The host does not expose a precise backend revision or context-window size. ## 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>	2026-10-28 09:07:17 -05:00
DottaandPaperclip	6ce0909db4	fix(agents): skip runtime probes for unchanged connections (#18016 ) ## Thinking Path > - Paperclip manages AI agents and their runtime settings. > - Operators save identity, model, connection, and run-policy settings from the agent page. > - PostgreSQL stores connection bindings as JSONB and can return keys in a different order. > - The save route compared JSON strings and treated an unchanged binding as a new connection. > - That false change started a remote runtime and credential probe during ordinary saves. > - This pull request compares binding values and checks real execution selection changes separately. > - Ordinary edits save without a probe. New connections and execution selections retain validation. ## Linked Issues or Issue Description Fixes #14518. Related work: #17760 also addresses prospective environment resolution. #14027 also adds explicit connection removal. This change is limited to the save validation gate and its regressions. What happened? A title-only save took 9.8–16.0 seconds in a hosted reproduction. JSONB key order made the unchanged AI connection look different. The route then waited for a remote runtime probe. Expected behavior Identity, thinking-effort, and run-policy edits skip the probe when the connection and execution selection stay the same. A changed connection, harness, model, provider, engine, or environment still validates adoption. Steps to reproduce 1. Save an agent with a managed AI connection in PostgreSQL. 2. Edit its title or thinking effort without changing the connection or execution selection. 3. Observe that the old route starts the adapter environment test. The fixed route saves without that test. ## What Changed - Use value equality for the stored and validated AI connection bindings. - Compare the effective execution selection separately. Preserve runtime probes for real selection changes and existing Copilot checks. - Add PostgreSQL route regressions for shared, delegated, default-user, and pooled bindings. Cover failed connection, model, engine, environment, and harness changes. - Keep the existing credential rejection and reconnect tests. Document the save behavior. ## Verification - `pnpm -r typecheck` passed on the rebased implementation. - Focused PostgreSQL 17 route selection: 21 passed, 58 excluded by the name filter. This covers ordinary saves, selection-change rejection, and credential health. - Full PostgreSQL 17 connection suite: 79 passed, zero skipped. Final `pnpm build` passed at `8fde75fa1a8fe63c71b05a3db149edf289295672`. - Before the fix, the PostgreSQL regression reached the unintended probe and failed for unchanged shared, delegated, and default-user bindings. The pool control passed. - An early controlled HTTP comparison of the binding fix used a synthetic 500 ms provider probe: five measured saves had a median of 798 ms before and 56 ms after. Probe count fell from five to zero. This is local supporting evidence, not a hosted latency result. - Earlier adjacent-route run: 159 of 160 tests passed. One existing roster-edit case exceeded its 15-second timeout. That case passed alone with the normal timeout. The cause of the earlier timeout remains unproven. - Local full-repository tests were not run. Native PostgreSQL startup fails because the host has exhausted System V semaphores. The focused tests use an isolated PostgreSQL 17 Docker fixture. - `git diff --check` passed. Hosted improvement remains unverified until deployment. - Greptile and Ponytail Paperclip Review both rated the exact head `8fde75fa1a8fe63c71b05a3db149edf289295672` 5/5, with no actionable defects. - CI attempt 1 passed 51 checks. Three self-hosted runners lost communication, interrupting the chat shard, serialized server shard, and canary dry run. GitHub annotations identify the runner communication failures; the serialized shard log also records a shutdown signal. Only those failed jobs were retried, once, on the unchanged commit. The [full CI workflow](https://github.com/paperclipai/paperclip/actions/runs/40692641103/attempts/2) then passed on attempt 2 at the same commit. All 55 passing checks and the legacy Snyk status are green; no checks remain pending. ## Risks This changes when connection adoption validation runs. Separate selection checks preserve validation for real runtime changes. Regression tests verify that rejected selections do not replace the saved configuration. Company access, connection authorization, activity records, and Copilot checks retain their existing paths. There is no schema or migration change. ## Model Used OpenAI Codex, configured model `gpt-6.1-sol` with ultra reasoning. Work used source inspection, shell tools, browser network timing, and PostgreSQL route tests. The context window size is not exposed by this session. ## 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>	2026-10-28 08:25:27 -05:00
Devin Foley devinfoley Claude Opus 5.5 Paperclip Amy	39279aa34f	feat(ui): shared error, connectivity and query foundation for disconnects (#15754 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The board reads API data and keeps the current task on screen. > - A restart or temporary network failure can interrupt those reads. > - Separate page error handlers can hide cached data or expose raw server codes. > - The app needs one connection state, readable error copy and a consistent read policy. > - This change provides that foundation and moves affected read surfaces onto it. > - The dependent write layer in #17960 preserves edits and submissions across the same failures. ## Linked Issues or Issue Description What happened? Temporary API failures could replace loaded content with errors. Different surfaces handled the same outage differently. Some showed raw server codes. A successful query to an unrelated service could also falsely report that Paperclip had recovered. Expected behavior Keep cached content visible. Show one connection banner during sustained trouble. Confirm recovery through the Paperclip health probe or its WebSocket. Retry transient reads and show readable errors for permanent failures. Steps to reproduce 1. Open a populated task or workspace page. 2. Interrupt API requests with a 503 or a dropped connection. 3. Keep an unrelated external request in flight. 4. Confirm that cached content remains and that the external result cannot clear the outage. 5. Restore the API and check that reads refresh. The write layer first merged into this feature branch in #15769 now has its own dependent PR, #17960. This PR contains the shared foundation and read changes. Merge this PR first. ## What Changed - Classify API errors and provide readable error copy, including non-JSON proxy responses and Retry-After handling. - Use one connection store and health probe with bounded backoff. Confirm recovery from the server health probe or live-updates WebSocket. - Pause reads while disconnected, retry transient errors, and refresh active reads after recovery. - Keep cached data visible through shared query views and affected page, panel and plugin read surfaces. - Add one app-level connection banner and support the pending-write count consumed by the dependent write layer. - Add a query-error rendering guard. Call it directly from the existing CI step. Update development documentation. ## Verification - Historical-chat lookup now follows the same ready/stale roster state as rendering. Three regressions fail before the fix; the six new cases pass after it, including working Retry, fresh data, no-cache error, permanent 403 and company isolation. All six focused query/recovery suites pass 200 tests. Final-commit CI passes and Apex is 5/5 with no unresolved findings. Canary Dry Run initially refused a preview version that was already on npm. It passed after one rerun with fresh registry metadata; no check was disabled. - Integrated current master and retained both transcript interest registration and connectivity reporting on socket open. The seven focused recovery/query suites pass 288 tests, and UI typecheck and production build pass. All 9,451 UI tests across 799 files pass on the merge commit. Final-commit CI passes and Apex is 5/5 with no unresolved findings. - Current head `70d9335d732219352ef0f98414439766bbcb33df`: all hosted CI checks pass. Apex is 5/5 on that head with no unresolved findings. The branch has no merge conflict. GitHub still requires code-owner approval. - The foundation passes 9,430 UI tests in 804 files. After integrating current master page paths, 190 focused page tests pass. - Two unrelated-success regressions fail before the latest fix. With the fix, 62 focused UI tests, all six guard tests and UI TypeScript pass. - The composed foundation and write layer pass 9,505 UI tests in 808 files, UI TypeScript, a production UI build, and query-error, token and map guards. - A real Chromium journey on the composed source injects a 503 during title save. The loaded task stays visible; one reconnect banner appears; the edit saves after recovery; another task stays unchanged; the saved title survives reload. - Full recursive local checks were not repeated because Runner compilation exhausted local disk during another repair. Hosted checks must pass before merge. No new staging deployment is claimed. - Latest review follow-up: a cached CaseDetail now survives a failed HTTP 429 refresh. Its page regression fails before the fix and passes after it. Eighty focused foundation tests, UI TypeScript, build and guards pass after that change. - Earlier CI evidence is retained: several foundation jobs received a runner shutdown signal together. The write-layer head also failed an unchanged Runner descriptor close test with `provider_transport_failed`. The same Runner source passed that suite in the foundation run. New CI runs cover the updated heads; no check or assertion was weakened. ## Risks - Shared retry defaults change the time before transient read errors appear. Permanent errors still fail promptly. - ApiError.message now contains readable copy. Callers that compare raw codes must use ApiError.code. - Cache success can come from another service or local data. It must not confirm Paperclip recovery. - Durable writes are reviewed separately in #17960. This PR does not change database or mutation contracts. ## Model Used Anthropic Claude Opus 5.5 (`claude-opus-5-5`) produced the original work with tool use. OpenAI Codex, GPT-6 family, assisted with restoration, integration, tests and review fixes. The Codex session does not expose its exact serving model ID or context window size. ## 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Amy (Opus) <claude@users.noreply.github.com>	2026-10-27 21:22:07 -07:00
Devin FoleyandPaperclip	6102f8e82c	fix: pass healthy managed Runner connection tests (#17965 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The board tests an agent's selected runtime and AI account. > - Cloud prepares and verifies the managed Runner runtime before execution. > - Its remote ACPX preflight reports that deferred step as a warning. > - The test keeps the warning after the selected account passes its hello probe. > - The board then asks the user to fix a healthy connection. > - This change makes that specific managed step informational after account verification. ## Linked Issues or Issue Description What happened? A Cloud agent's Claude connection test passes with Legacy. With Runner, the same account completes the Claude hello probe but shows "Connection needs attention." The only warning says that remote runtime preparation must occur before launch. Expected behavior A verified managed connection passes when its only warning concerns runtime preparation that Paperclip performs before execution. Failed authentication and actionable runtime checks retain their results. Steps to reproduce 1. Select a working Claude subscription on a Cloud-managed sandbox. 2. Select Runner and run the connection test. 3. Observe a successful Claude hello probe and a warning result. Related: #17961 covers managed OpenRouter model verification. #15880 adds persistent computer runtime interfaces. Neither changes this Cloud connection-test status. ## What Changed - Recognize the deferred ACPX runtime check after a provider hello or live API-key verification succeeds. - Report that check as informational for Cloud-managed sandbox connections. - Preserve every other warning and error, including unexplained warning results. - Add service regressions and document the test/launch boundary. ## Verification - Red: the healthy managed-Claude case returned `warn` after a successful hello. The regression fails before the change and passes after it. - 116 tests pass across connection verdicts, environment-test HTTP routes and adapter registration. Scoped server TypeScript and the server build pass, including the native Runner build. - Negative cases cover rejected credentials, missing hello receipts, missing runtime packages, actionable or unexplained warnings, self-hosted instances, SSH targets and unexplained provider warning results. API-key success requires live provider re-verification. - Operator evidence confirms that the reported test lease was released with cleanup successful. The agent's saved adapter is Legacy. No saved account, agent or environment setting was changed. - A clean local install hit a frozen-lockfile `patchedDependencies` configuration mismatch. The scoped checks reuse installed workspace dependencies. The final commit has passing hosted CI, including clean-install typecheck, tests and build, and Apex 5/5 with no unresolved findings. - A cold HTTP-suite module load reached the 30-second setup limit while other checks ran. All 54 HTTP cases pass on retry, and the full focused run passes 116 tests without changing assertions or time limits. - No staging deployment is claimed. This change classifies the connection-test result; it does not claim that a native Runner hello turn was performed. ## Risks - This status change is limited to a verified Cloud-managed sandbox ACPX connection and the exact deferred check code. The provider's successful receipt is required. - Runtime package preparation and verification still execute before agent work. A connection test does not replace those launch checks. - There is no schema, permission or credential change. Local, SSH and plugin task probes keep their existing verdicts. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository inspection, tool use and code execution. The session does not expose its exact serving model ID or context window size. ## 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 #` 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>	2026-10-27 20:34:10 -07:00
DottaandPaperclip	09d4ca533e	perf(server): return only sidebar failure badge candidates (#17935 ) <!-- entire-trail-link-start --> https://entire.com/gh/paperclipai/-/trails/95/changes/paperclip/95 <!-- entire-trail-link-end --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The sidebar badge shows failures that need attention. > - The service reads the newest 200 runs before it selects one run per agent. > - Most of those rows cannot contribute to the failure count. > - This pull request selects failure candidates in SQL and returns four required fields. > - The benefit is less database response data with the same badge and access rules. ## Linked Issues or Issue Description Refs: #12770. Refs: #17756. Refs: #17683. These are related load, inbox, and badge reports. This implementation was written independently from the current service. It does not change which issue states count as failures. What existing behavior does this improve? The run read used by the company sidebar badge. Current behavior Every call transfers up to 200 rows with eight scalar fields. The application then selects the latest run per agent and applies status, Mine, dismissal, and access rules. Proposed behavior SQL selects the same latest run per agent from the same 200-row window. It then applies status and Mine rules. It returns only the run ID, scope, issue ID, and creation time. The service still checks dismissals and current issue access. Reason and benefit A mixed synthetic fixture reduces the response from 30,689 to 1,297 value bytes. The complete badge response stays equal. Breaking changes None. The endpoint response and the 200-run window stay the same. ## What Changed - Keep company and active-agent filters before the existing 200-row limit. - Rank each agent by the full creation timestamp in descending order, then by the observation ordinal. The timestamp order explicitly selects the newest run. Exact ties retain the first observed row. No ID tie-break is added. - Apply failure and Mine filters after ranking. A shared agent's success cannot expose an older failure. - Return four fields for dismissal and fresh issue authorization. Supply the already constrained company ID in the service. - Add real PostgreSQL regression fixtures and a service-generated SQL comparison harness. Document the command in `doc/DEVELOPING.md`. ## Verification - `pnpm -r typecheck` passed. `pnpm build` then passed in a separate sequential step. The normal Runner verifier checked 1,509 inputs and 1,555 outputs before reuse. - `PAPERCLIP_SIDEBAR_TEST_DATABASE_URL=<dedicated-test-url> pnpm --filter @paperclipai/server exec vitest run src/__tests__/sidebar-badges.test.ts` passed all 14 tests on PostgreSQL 17.11. - The 10 unchanged `inbox-dismissals.test.ts` route tests passed against the same real PostgreSQL server through a temporary local adapter for database startup and cleanup. The adapter was removed. The standard host run passed the 13 new tests and skipped those 10 embedded-PostgreSQL tests. - The first focused attempt could not import the unbuilt plugin SDK. The normal build supplied that package before the passing reruns. - `pnpm test:run` was attempted. It recorded 16 embedded-PostgreSQL startup failures in the unrelated native-session executor suite. Other database suites also reported startup failures and skipped. The owned command was then stopped with exit 143. This is incomplete local full-suite evidence, not a pass. Full remote CI passed on final head `df5b2c81af43c282d031cc37e6bc867054217df5`: 54 successful checks, 2 neutral checks, and 2 optional Storybook skips; no pending or failed checks. Fresh exact-head Greptile review is 5/5 with zero unresolved threads. - A fixture rollback test reproduced the review finding before the fix: a failed final approval insert left 2 companies, 44 agents, 2 issues, and 657 runs. After the fix, the same PostgreSQL constraint error leaves zero owned rows in all five tables. The test also confirms that more than 600 runs were written before the deliberate failure. - Fixture seeding now uses one transaction, including the submillisecond SQL insert. The 14 focused tests and all 10 benchmark cases pass after this repair. The server typecheck also passes. Production SQL is unchanged. - The final ordering repair passed all 14 real-PostgreSQL tests, all 10 pinned-baseline benchmark cases, and affected server typecheck and build, run sequentially. The plans now explicitly sort by agent ID, full creation time descending, then observation ordinal. Complete badge responses and candidate bindings remain equal. - One server-test shard was interrupted by its CI runner receiving a shutdown signal. Its test step was canceled without an assertion failure. A single targeted retry passed; the aggregate `ci / verify` gate also passed. No source change was needed for that interruption. - `git diff --check` passed. No schema, workflow, or lockfile changed. Reproduce the benchmark with current schema migrations and a dedicated synthetic database whose name ends in `_test`: ```sh PAPERCLIP_SIDEBAR_TEST_DATABASE_URL=<dedicated-test-url> PAPERCLIP_LOG_LEVEL=error SIDEBAR_REQUIRE_BYTE_REDUCTION=1 pnpm --filter @paperclipai/server exec tsx ../scripts/benchmark-sidebar-badges.ts --baseline-ref=bf3ef12f3a78d0b15a32ad57f7e16520fbf6cd5e ``` The harness loads the baseline service from that commit. Its authorization, privacy, and shared helper dependencies are unchanged. It captures the SQL each service executes. It compares complete badge responses and every returned candidate field. Fixtures cover more than 200 runs, shared agents, superseding successes, exact and submillisecond ties, Mine user variants, dismissal equality, private and deleted issues, missing issue bindings, terminated agents, and cross-company rows. Tests also cover absent actors, grants, revocation, deletion after a prior read, and index versus sort plans. Synthetic local SQL results from PostgreSQL 17.11 on Docker, Node 24.22.1, and postgres.js 3.4.9 follow. Each timing is the median of seven alternating warm samples after two warmups. The report includes all samples, ranges, settings, SQL, parameters, and `EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)` plans. \| Fixture \| Rows before → after \| Value bytes before → after \| Reduction \| Median ms before → after \| \| --- \| --- \| --- \| --- \| --- \| \| Mixed, company-wide \| 200 → 18 \| 30,689 → 1,297 \| 95.8% \| 1.361 → 1.305 \| \| Mixed, user-1 \| 200 → 9 \| 30,689 → 676 \| 97.8% \| 1.785 → 1.391 \| \| Mixed, local-board \| 200 → 6 \| 30,689 → 414 \| 98.7% \| 1.463 → 1.232 \| \| All failed, 200 distinct latest agents \| 200 → 200 \| 30,298 → 13,778 \| 54.5% \| 1.277 → 1.237 \| \| All succeeded \| 200 → 0 \| 30,898 → 0 \| 100% \| 1.095 → 0.898 \| \| Empty \| 0 → 0 \| 0 → 0 \| Neutral \| 0.703 → 1.002 \| Value bytes mean UTF-8 non-null cell values before Drizzle decoding. They exclude PostgreSQL protocol framing and are not wire bytes. The primary claim is less response data. Warm timing ranges overlap. Earlier all-failed samples were slower, and the empty control remains slower. SQL adds ranking work. No production latency improvement is claimed. The plans keep the limit below both window operations. ## Risks - SQL adds two bounded window operations. The all-failed control transfers fewer bytes but can take more SQL time. - Per-agent ranking explicitly orders by full creation time descending. Exact timestamp ties retain the observation ordinal. Real PostgreSQL tests compare complete candidates with the original helper under index and sort plans. - Mine rules now also have a SQL form. Tests cover undefined, null, empty, named, and local-board users, including empty responsible-user IDs. - Issue access stays fresh and fail closed. No authorization result is cached. No migration or stored run change is required. > 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 GPT-6 through Codex. The exact serving model ID and context window are not exposed in this session. The model used reasoning, code execution, SQL inspection, and GitHub 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>	2026-10-27 16:32:09 -05:00
DottaandPaperclip	56bc470ab2	perf(server): project continuation history result fields (#17930 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - A continuation carries completed tool receipts so the agent can avoid repeat actions. > - It also checks saved conversation and workspace recovery fields before choosing a prior terminal run. > - The history query transfers every result field for every matching run. > - Native output and unused receipt request fields can make this read large. > - This pull request selects the fields those consumers use and keeps each completed receipt result in full. > - The benefit is less database transfer with the same history, recovery decisions, and completed-action evidence. ## Linked Issues or Issue Description What existing behavior does this improve? The history read in `buildExecutionContinuation`. Current behavior The query returns complete `result_json` values for all matching runs. Consumers read completed receipt state, operation ID and result, plus conversation and workspace recovery controls. Large native output and receipt request fields cross the connection without being used. Proposed behavior Select only those result fields in PostgreSQL. Keep typed policy and recovery values. Keep all eligible completed receipts and their complete result values. Retain missing versus null receipt results, run and receipt order, company/task/agent scope, and the source-run exception. Keep the full retained history without a new limit. Reason and benefit The synthetic wide-output fixture removes 99.879% of this query's DataRow bytes. A required 2 MiB receipt-result control saves only 0.0074%, because that complete result is needed. Actual savings depend on result contents; the wide-output result is not a forecast for all deployments. Breaking changes None intended. No schema, API, migration, workflow, history limit, or receipt truncation changes. Additional context Related: #17481 projects a separate recovery read, and #17896 narrows explicit continuation admission. This PR covers the continuation history query and has no dependency on the other byte reduction PRs. ## What Changed - Project completed tool receipts to their state, operation ID and complete result. Omit fields that the continuation does not read. - Project typed conversation/workspace controls and the recovery schema. Keep the shared policy helper unchanged. - Add real PostgreSQL comparisons for complete continuation envelopes, ordering, scope, legacy JSON, recovery flags, and receipt result preservation. - Add external isolated database support to the existing continuation tests and document a reproducible query benchmark. ## Verification - Pinned baseline: `3cd3af5d75f200185ed4d9703a3145594a489b13`. - PostgreSQL 17.11 with synthetic local data. The harness captures SQL from the real baseline and treatment services. Imported helpers remain unchanged. - Command: `pnpm --filter @paperclipai/server exec tsx ../scripts/benchmark-continuation-history.ts --baseline-ref=3cd3af5d75f200185ed4d9703a3145594a489b13`. Set `PAPERCLIP_CONTINUATION_HISTORY_BENCHMARK_DATABASE_URL` to a disposable database ending in `_test` to use an external server. The default uses disposable embedded PostgreSQL. - The baseline was measured before the production edit with `--baseline-only`. The treatment compares complete envelopes, every retained scalar column, completed receipts, and shared policy decisions. The wide unused-output fixture must remove more than 90% of DataRow bytes or the benchmark fails. - Wide unused-output fixture: 25 runs with independent incompressible 192 KiB native output and 32 KiB unused receipt request fields. DataRow bytes: 5,744,950 to 6,925 (99.879% less). - Required-result control: one complete 2 MiB receipt result. DataRow bytes: 2,097,556 to 2,097,401 (0.0074% less). The whole result is checked for equality. - Exact byte boundary: PostgreSQL text-format DataRow frames, including field length prefixes. Excludes RowDescription, command metadata, TLS, TCP, and other service queries. - Seven measured query round trips per variant follow two warmups and alternate order. Final-head wide-output median: 32.86 to 4.41 ms (ranges 26.24–35.54 and 3.62–5.21 ms). Required-result median: 17.01 to 20.60 ms (ranges 16.30–32.89 and 18.85–22.48 ms). The required-result control shows projection overhead and overlapping timing ranges; it has no latency improvement claim. These are local measurements, not deployed latency results. - `PAPERCLIP_EXECUTION_CONTINUATION_TEST_DATABASE_URL=<isolated_test_database> pnpm exec vitest run server/src/services/execution-continuation.test.ts server/src/services/execution-continuation-history-read.test.ts --maxWorkers=1`: 55 tests pass in PostgreSQL 17. - Cases cover numeric receipt key order, empty operation IDs, malformed receipt entries, missing versus null results, complete large results, malformed root JSON, all closed workspace restore failure codes, invalid recovery schemas, cancelled admission rows, and company/task/agent/source-run boundaries. - `pnpm -r typecheck` and `pnpm build` pass on final head `d665d9f5c47b237c81b9cc80fdec1d39ad90754f`. The final-head focused PostgreSQL run passes all 55 tests. The final benchmark records that SHA, an empty source diff, and passing equivalence/byte assertions. The first typecheck found optional array accesses in new test assertions; explicit required-array assertions fixed them. Local full `pnpm test:run` is not claimed because the host embedded PostgreSQL runtime is unavailable; the full test matrix runs in CI. Exact-head Greptile review completed success at 5/5 with no actionable findings or unresolved threads. The full final-head CI matrix passes. All 58 current-head checks are terminal: 54 success, two neutral, and two optional Storybook skips. One original server shard ended with a canceled test step and no assertion failure; its single targeted retry passed. No product change was needed for that interruption. ## Risks - Future continuation consumers must add any newly required result field to this projection. Existing shared policy semantics stay in the helper. - Completed receipt results can still be large and can dominate transfer. This PR preserves them without a cap. The receipt-heavy control adds JSON projection work for only 155 bytes of savings, so it can be slower despite equal output. - JSON malformed-value and property-presence rules affect action evidence and recovery. Real PostgreSQL comparisons check those decisions and complete output. - Production transfer and latency improvements need a fresh deployed capture. Nothing was merged or deployed by this work. ## Model Used OpenAI GPT-6 through Codex. The exact runtime model ID and context window are not exposed by this session. The work used repository tools, code execution, and real PostgreSQL validation. ## 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>	2026-10-27 16:30:37 -05:00
DottaandPaperclip	f60ac29cf1	fix(runner): migrate Grok Build with native reasoning effort (#17922 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Harness selection maps supported agents to Paperclip Runner. > - The native Runner already supports Grok Build, but its migration mapping excludes Grok. > - Grok agents also have a thinking-effort setting that the native execution contract does not carry. > - This pull request adds the migration path and preserves explicit Grok effort through startup and resume. > - Operators can upgrade an existing Grok agent without silently losing its model, account, or effort. ## Linked Issues or Issue Description What happened? Existing Grok Build agents have no Runner selector or upgrade action. Adding only the mapping would route conversion through the Codex fallback and lose Grok execution semantics. Native execution also ignores the legacy reasoning-effort field. Expected behavior A qualified Grok agent can explicitly upgrade. The saved model, account, instructions, history, and supported effort remain intact. Unsupported legacy settings fail before saving. The provider must acknowledge the selected effort before inference. Steps to reproduce 1. Open the runtime page of an existing Grok Build agent on a qualified Linux x64 or macOS ARM64 computer. 2. Observe that the Runner selector and upgrade action are absent. 3. Compare the native execution input with the saved legacy reasoning-effort setting. Related work: #13882 introduced native Grok Build. #15422 covers the earlier default-runner work. This change extends the current shared selection contract. ## What Changed - Add the Grok harness mapping, qualified platform limits, upgrade action, and company-scoped computer qualification. - Translate Grok settings to ACPX without changing the selected account or explicit model. Resolve the legacy default model to the native default. Preserve the effective legacy search policy. Reject incompatible command, argument, permission, and turn-limit settings. - Add native execution input v10 for explicit Grok effort and search policy. Preserve historical schemas. Enforce disabled search through Grok requirements and bind it across startup and recovery. - Apply and verify ACP `reasoning_effort` before prompting. Bind the value to provider descriptors, checkpoints, runtime identity, and resume checks. - Use the Grok catalog and effort choices in the task composer. Apply task model and effort overrides while retaining the agent account and search policy. Update runtime controls, portability/default handling, documentation, and capability maps. - Advance Pi and Copilot source attestations for changed shared transport and recovery code. Keep historical identities intact and update all Rust integration fixtures. ## Verification - Migration and review regressions were reproduced before the fixes. Coverage includes the Grok mapping, default model, explicit effort, implicit search policy, task overrides, and incompatible legacy settings. The broad migration, route, immutable-input, and composer check passed 478 tests. The final catalog and task-input check passed 135 tests. - Runner startup, recovery, search policy, and profile checks passed 361 tests, with one platform skip. The final source-identity, search-admission, and transport event-pump check passed 89 tests. - All 757 Rust workspace tests passed for the broad implementation. After the final source attestation update, all 55 ACPX profile/session tests passed. - `pnpm -r typecheck` and `pnpm build` passed for the implementation. Server and Runner typecheck passed after the final production change. Server `tsc --noEmit` passed after the final test-fixture change. Docker context integrity, token gates, maps, generated protocol data, and replay goldens passed. - The v10 startup fixture initially used an ambient local Grok login and failed on CI. An explicitly empty credential home reproduced all four failures. The fixture now supplies a synthetic key and a private empty home. A separate case checks that missing credentials fail closed. All seven selected Grok v10 and Claude v9 startup cases pass without host credentials. - The full local suite could not complete because embedded PostgreSQL failed before database-backed fixture setup. The broad executor-suite attempt hit the same limit and was stopped. Neither attempt is counted as passing. Current-head CI must verify those paths before merge. - Earlier CI found missing Rust input fields, stale source attestations and exact fixture pins, a missing Docker context entry, and an outdated import expectation. Those failures were fixed and checked locally. The CI logs retain the original failures. - Different earlier CI runs also failed unchanged cleanup pagination, device-login timeout, and chat lost-response recovery cases. Later attempts passed the cleanup and login cases without changes to those implementations. Their causes remain unproven. The original evidence remains in [the first run](https://github.com/paperclipai/paperclip/actions/runs/40563402840), [the login run](https://github.com/paperclipai/paperclip/actions/runs/40571128328), and [the chat run](https://github.com/paperclipai/paperclip/actions/runs/40573072163). A passing retry does not establish a root-cause fix. - Both reviews rate current head `16fba9b4cdf12bc7945e6628912e79da42959f35` 5/5. All current-head CI gates pass in [run 40576580699](https://github.com/paperclipai/paperclip/actions/runs/40576580699). All 60 check runs completed cleanly, including the four intentional skips and the neutral 5/5 Paperclip review. The legacy security status is successful. No review threads remain unresolved. - Staging migration and a real shell task are pending deployment. This PR does not claim full Grok provider qualification. Reviewers can verify the operator path by upgrading a qualified Grok agent, checking its saved model and effort, and running a shell task through native execution. ## Risks - Explicit effort and search policy require the matching Runner and sidecar build. Older immutable execution inputs keep their existing schemas. - Providers that omit or reject the selected effort fail before a prompt. Unsupported effort does not fall back silently. - Existing agents retain their saved runner until an explicit change. New Grok agents use native execution only on qualified platforms. - Grok token and cost reporting remain unverified, as before. ## Model Used OpenAI Codex, GPT-6 family. The exact serving model ID and context-window capacity are not exposed in this session. Used reasoning, source editing, shell execution, and browser inspection. ## 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 and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and the focused suites pass; the full local suite has the environment limitation recorded above - [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>	2026-10-27 15:28:42 -05:00
Dotta Paperclip Paperclip	3cd3af5d75	Trace native preparation and OpenCode execution phases (#17918 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Each native run prepares its workspace and skills, then starts its provider. > - A long preparation span does not show whether inventory refresh, a cache lock, repository reads, or file checks caused the delay. > - One hosted run spent 81 seconds in this phase. The same deployed service and pinned files took 2.55 seconds in a separate diagnostic process. > - Another hosted turn spent 69 seconds before its first output. A matched public-workspace local model replay took 7.64 seconds. > - We need skill preparation and provider-internal measurements before choosing another fix. > - This pull request adds skill spans, a real-service benchmark, and opt-in filtered provider timing. > - The benefit is a faster and more precise diagnosis loop. ## Linked Issues or Issue Description Refs #17620. That PR owns the batched read optimization. This PR adds diagnostics and does not change its read policy. Refs #17907. That PR protects long cache lock transactions from the database idle timeout. What happened? Native skill configuration can take much longer than matched standalone resolution. Provider execution also has long gaps with no internal timings. Existing spans cannot separate inventory refresh, cache acquisition, repository reads, context loading, Git snapshots, or model streaming. Expected behavior An operator-configured trace shows these phases under the existing run context. Without an OTLP endpoint, the new spans stay off. A local benchmark can reproduce the service path with real PostgreSQL, files, an agent actor, and a responsible user. Steps to reproduce 1. Run `pnpm --filter @paperclipai/server exec tsx scripts/benchmark-native-skill-preparation.ts --actor=agent --staging-shape=true`. 2. Inspect cold and warm phase timings, SQL counts, and file verification results. 3. Set the existing operator OTLP configuration and add `--export-otlp=true` to inspect the same hierarchy in the collector. ## What Changed - Add bounded skill inventory, refresh wait, cache acquisition, row, version, repository, file check, and consumer spans. - Keep the existing endpoint gate, attribute allowlist, cache locks, authorization, file validation, and durable pin boundary. - Add a standalone benchmark with a full repository fixture, immutable snapshot input, calibrated local transport delay, and optional OTLP export. - Verify every delivered file and executable bit outside the timed section. Create its fixture agent through the lifecycle API. - Add an opt-in authenticated loopback sink for OpenCode. Discard raw attributes, logs and content. Retain only closed phase names and timestamps. - Carry one bounded diagnostic batch through the real proxy, Rust normalization, durable journal and server trace projection. Group provider phases under their execution parent. - Freeze the Date clock in an existing delegated Slack rate-limit test. This fixes a CI failure when consecutive requests cross a rate-window boundary. It does not change rate-limit behavior. - Document phase boundaries and the difference between SDK startup and confirmed ingestion. ## Verification - Skill service, runtime selection, concurrency, cache and timing suites: 122 tests passed with real PostgreSQL and migrations. Enabled-span integration tests also passed. They verify parent relationships and a real advisory-lock timeout. - A captured 208-file repository produced 209 verified runtime files. The benchmark uses real agent and responsible-user authorization. The lifecycle fixture correction passed with the staging-shaped inventory. - Affected OpenCode driver, collector and transport tests: 72 passed. The tests cover authentication, content removal, size/count bounds, disabled behavior and the rebuilt native Runner boundary. One Rust projection test and 18 server trace tests also passed. A held run-log sink proves that a full 128-span diagnostic batch adds no duplicate database writes before terminal consumption. - The two CI-failing delegated Slack rate-limit cases passed against real PostgreSQL with only the Date clock frozen. - Runner TypeScript and server TypeScript checks passed. Rust formatting and module-boundary checks passed. - Real Honeycomb readback confirmed the 14-span skill waterfall and a 40-span provider waterfall. Provider phases have the correct execution parent. The provider export uses synthetic model replies and is instrumentation proof only. - Earlier full local checks failed on missing package-local executables, then on the default Node heap and a missing generated service worker. The dependency links were repaired. The server check passed with a larger heap. The full local test attempt could not start embedded PostgreSQL on this host and was stopped after retaining its failures; real database coverage uses an isolated database on an existing local server. These attempts do not count as a full local pass. - CI on the prior revision passed typecheck, build, Runner and all E2E shards. It failed the benchmark lifecycle boundary and one existing rate-window test. Those fixes passed CI. A later Runner assertion exposed the Copilot source identity pin on the shared transport file. The diagnostic flag now uses the existing configured-environment projection, preserving that file byte-for-byte. All 66 selected installation and native transport tests passed. New-head CI and review remain required. - The under-15-second hosted response target remains unmet. This PR adds diagnostics and does not claim a hosted latency fix. ## Risks - Skill spans and Honeycomb export retain the operator endpoint gate. OpenCode phase collection requires a separate explicit diagnostic flag. Without an endpoint, its closed measurements stay in the instance run log. - Raw OpenCode OTLP can contain prompts and authorization attributes. The new sink rejects unauthenticated requests and discards all attributes before any measurement reaches PRP or the operator collector. Request, event and per-phase limits bound memory and journal growth. - Collection does not wait for a provider flush. Late or oversized exports can be absent; these measurements are not a complete profiling guarantee. - The benchmark's inventory contents and transport delay are explicit fixtures. They do not reproduce server contention or prove hosted response time. - The one durable diagnostic batch remains the local evidence. Its child span export does not add per-phase run-log rows. - No database migration, authorization policy, model selection or inference transport changes. The Rust Runner and OpenCode proxy must be shipped together for the new opt-in diagnostic. ## Model Used OpenAI GPT-6 through Codex, with repository inspection, shell execution, browser tools, and Honeycomb queries. The session does not expose a verifiable backend deployment ID or context-window size. ## 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 - [ ] All Paperclip CI gates are green - [ ] 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> Co-authored-by: Paperclip <paperclip@paperclip.ing>	2026-10-27 14:53:32 -05:00
DottaandPaperclip	f6ba9afab0	perf(server): narrow explicit continuation run reads (#17896 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Recovery must prove that old execution stopped before it admits new user input. > - Explicit continuation reads the source run before and after it takes the run lock. > - Both reads transfer the saved prompt and the full Runner profile. > - The preflight needs only identity, comment, adapter, and workspace receipt fields. > - This pull request narrows those reads and keeps the complete locked profile for session proofs. > - The benefit is less database transfer with the same admission and recovery rules. ## Linked Issues or Issue Description What existing behavior does this improve? Explicit native continuation admission after a failed or stopped run. Current behavior The preflight and locked reread select complete heartbeat run rows. Large saved contexts and execution profiles cross the database connection twice. Proposed behavior Read only required scalar fields and typed context keys. Read only historical adapter identity and workspace sync receipts before the lock. Keep the complete Runner profile in the locked reread. Keep lock order, company scope, text lookup of historical run IDs, stop proofs, queued input, and replay rules. Reason and benefit A synthetic PostgreSQL 17 fixture removes 74.9% of the two queries' DataRow bytes. This result is local query evidence. It is not a claim about deployed latency or monthly transfer. Breaking changes None intended. No schema, API, migration, workflow, or dispatch contract changes. Additional context Related: #17491 narrows the separate execution blocker read path. This PR covers explicit continuation admission. The PR has no dependency on the other byte reduction PRs. ## What Changed - Select required continuation fields and typed context keys instead of complete run rows. - Read a small historical adapter/workspace profile during preflight. Preserve the full locked profile for exact suspended-session and quarantined-cleanup proofs. - Narrow four helper input types to their actual field requirements. Their runtime behavior is unchanged. - Add real PostgreSQL admission comparison coverage and a reproducible baseline/treatment benchmark. - Document the query boundary and benchmark command. ## Verification - Baseline: `663fe667d66d3863d0919a8724f1d99500feef0b`. - Disposable PostgreSQL 17.11. One source run has a 192 KiB incompressible context and two 96 KiB profile payloads. - Command: `pnpm --filter @paperclipai/server exec tsx ../scripts/benchmark-continuation-run-reads.ts --baseline-ref=663fe667d66d3863d0919a8724f1d99500feef0b`. Set `PAPERCLIP_CONTINUATION_BENCHMARK_DATABASE_URL` to a disposable database ending in `_test` to use an external server. - The harness captures SQL generated by both real service versions. Baseline imports use current helpers; only their TypeScript input types changed in this PR. Their runtime behavior stays fixed. - Preflight DataRow bytes: 394,067 to 466 (99.88% less). Locked reread: 394,067 to 197,168 (49.97% less). Combined: 788,134 to 197,634 (74.92% less). - Byte counts cover exact PostgreSQL text-format DataRow frames. They exclude RowDescription, command metadata, TLS, TCP, and other queries in the service. - Seven measured samples per query follow two warmups. The order alternates. Final-head median preflight time: 6.53 to 2.28 ms (ranges 5.34–7.41 and 1.84–4.46 ms). Median locked read: 8.06 to 5.26 ms (ranges 5.94–13.84 and 4.61–6.81 ms). These are warm local SQL measurements under shared machine load. The deterministic byte counts are the acceptance criterion; these noisy timings do not establish a deployed latency gain. - The harness compares the admitted continuation, blocked reasons, every retained scalar column, kept JSON, and the full locked profile. It fails unless the fixture removes more than half of the two reads' DataRow bytes. It records SQL, parameters, revision identity, samples, and EXPLAIN plans. - All 291 continuation tests pass together on the final head with no skips in a clean isolated PostgreSQL 17 database. This includes all seven new projection comparisons and six malformed/missing JSON cases. - Edited server TypeScript check passes: `node node_modules/typescript/bin/tsc --noEmit -p server/tsconfig.json`. - `pnpm -r typecheck` and `pnpm build` pass on the final head. The normal server build verifies the complete pinned Copilot closure. Local full `pnpm test:run` is not claimed: host embedded PostgreSQL startup limits prevent that gate. The isolated PostgreSQL regressions pass; the full exact-head test matrix runs in CI. The targeted exact-head test retry passes all 4,086 tests in 98 files. All CI verification checks and the dependent aggregate are complete and successful on head `47c1b5f7d17a58310f7a3ebd494fdcaa814777c2`. Greptile completed cleanly on head `47c1b5f7d17a58310f7a3ebd494fdcaa814777c2`: 5/5, no findings, and no unresolved review threads. - Local setup evidence: embedded initdb could not load its ICU data library. Tests therefore use a dedicated PostgreSQL 17 container. A run against reused test fixtures produced stale sweep failures; a new clean database passed all 285 cases. The first comparison mock replaced an unrelated aliased query; it was narrowed to the two admission reads before the clean pass. - The first [server test shard 6/12](https://github.com/paperclipai/paperclip/actions/runs/40529210562/job/122277218565) failed one existing workspace-recovery case: a third export stayed `scheduled` at its 20-second poll deadline; 4,085 other tests passed. The exact case passes on the pinned baseline and final head with the same PostgreSQL 17 fixture. Temporary spies recorded zero calls to both changed admission functions in either replay. Other touched helpers have type-only changes. This supports one timing-flake retry; the exact scheduler delay remains unproven. The single [targeted shard retry](https://github.com/paperclipai/paperclip/actions/runs/40529210562/job/122285744135) passes all 4,086 tests in 98 files. The exact case completes in 17.25 seconds. The dependent aggregate is complete and successful. No timeout or unrelated runtime code was changed. - The separate Paperclip Review check ended `NEUTRAL` without a final report. The completed source review is the exact-head Greptile 5/5 result above. ## Risks - A future admission check may need an additional saved context key. Keep the projection and helper contracts in sync with that consumer. - Exact suspended-session and quarantined-cleanup proofs still require the complete Runner profile. This PR retains it under the lock rather than weakening those checks. - JSON values retain their types and missing keys stay absent. Malformed-context comparisons preserve the existing controller hold. - These measurements use synthetic local data. Deployed transfer savings require a fresh capture after rollout. Nothing was deployed. ## Model Used OpenAI GPT-6 through Codex. The exact runtime model ID and context window are not exposed by this session. The work used repository tools, code execution, and real PostgreSQL validation. ## 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>	2026-10-27 12:05:51 -05:00
Nicky LeachandPaperclip	835966dec8	Prepare agent-owned environments during hiring (#17761 ) <!-- entire-trail-link-start --> https://entire.com/gh/paperclipai/-/trails/1/changes/paperclip/1 <!-- entire-trail-link-end --> ## Thinking Path > - Paperclip manages agents and their execution environments. > - New agent setup saves an inactive agent before model connection tests. > - Some plugins need that agent to prepare its execution resource. > - The wizard tested without the agent ID, while the setup hold prevented preparation. > - Environment changes also discarded the selected model account. > - This change prepares the saved draft during setup and keeps normal execution held. > - Users can test the prepared resource before they finish hiring. ## Linked Issues or Issue Description What happened? An agent-owned plugin environment could not acquire a test lease during hiring. Changing environments also returned the user to Connect and cleared the selected account. Expected behavior Keep the selected account, invalidate its test, and prepare the saved agent resource in the background. Test that same agent before finishing setup. Steps to reproduce 1. Start a new Claude or Codex agent and select a saved account. 2. Change to an agent-owned plugin environment. 3. Try to finish setup or reconnect the account. Related: #17750 defers probes until after hire submission. This change implements preparation during the wizard instead. The related PR search and ROADMAP review found no other implementation of this setup preparation path. ## What Changed - Add the optional `requiresAgent` driver declaration. Require agent lifecycle participation when it is set. - Prepare saved drafts on creation or environment changes. Keep the setup hold and wait in `verifying` without background verification scans. - Bind tests to the saved agent. Return a warning without allocating a lease when the required agent is absent or still preparing. - Preserve the account and configuration step when the environment changes. Save the selection and invalidate the old test. - Show active preparation and support authorized retries. Keep approval, company, budget, and normal task admission controls. - Document the contract and cover lifecycle, lease, manifest, and wizard behavior. ## Verification - Server and UI TypeScript checks passed. - 112 wizard and setup helper tests passed. The shared manifest suite passed. - 123 lifecycle, policy, lease, and environment-test API cases passed after the approval-gate fix. The diagnostic and driver suites and all 80 agent adapter route tests also passed. - Token gates, module boundaries, map validation, and whitespace checks passed. - All 66 lifecycle/policy cases passed after the stopping-draft permission fix. The new real-DB route case verifies creator success, other-creator denial, and refusal to complete a hire while stopping. - Full workspace typecheck and build were attempted. Both stop at the unchanged Rust Runner step because Cargo is not installed on this host. - CI on `43be3c93d` passed all automated checks, including full test shards, typecheck, build, Rust checks, browser suites, and canary checks: https://github.com/paperclipai/paperclip/actions/runs/40368174530. - The full local repository test command was started. Two unchanged workspace tests assume Git's initial branch is master; this host defaults to main. Both fail in isolation under the host default and pass with process-scoped init.defaultBranch=master. The broad run was stopped after those confirmed fixture failures; CI supplies the full clean check. - Early new-test failures were fixture collisions and an unscoped sweep assertion; the fixtures and assertion were corrected. One route-suite load raced with SDK output regeneration; rebuilding first and running the suite afterward passed. - Initial CI exposed a route mock missing the new prerequisite lookup. The fixture was updated and a real HTTP no-lease case was added; all 54 cases in that route suite pass. Security review identified allocation before required approval; the new approval gate and its tests address it. - CI on `50b5a08af` reported 32 of 33 expected calls in the unchanged cleanup-history scheduling test. Its isolated case passed locally without cleanup-code changes; the original failure remains recorded and the final CI run passes on the current head. - Standard Greptile reviewed `43be3c93d` at 5/5. A subsequent deeper review identified runner selection, stale detail reads, error retention, and test file size issues; 70343387b addresses all four with resolved threads. Standard review returned 5/5 on that commit and again on rebased head `fda42c5ab`. The rebase preserves master's new managed environment skill declarations alongside requiresAgent. Full CI on `fda42c5ab` passes: 55 successful checks, two intentional skips, no failures. Run: https://github.com/paperclipai/paperclip/actions/runs/40405121641. - After those fixes, 133 UI tests and 61 lifecycle/policy cases pass; all eight focused UI regressions fail against the previous implementation and pass with the fix. Token, map, and whitespace gates pass. The stale-read fixture initially omitted the setup URL because navigation is mocked; following the URL activates the real detail query and reproduces the race. - UI TypeScript passes. This host's server dependency links now point to a separate scratch checkout lacking requiresAgent, so the ordinary server check reports that missing property. A no-emit check pinned to this branch's shared declarations passes; it disables declaration generation and supplies explicit local type roots. The first temporary configuration lacked those type roots; the corrected configuration passes. CI remains the full workspace verification. - After rebasing onto `8373d7867`, all 133 UI, 61 lifecycle/policy, and 44 manifest cases pass again, as do UI TypeScript, token, map, and whitespace checks. The server no-emit check now hits three mismatched SDK/Runner declarations from the scratch dependency links; these are outside this change. Full CI builds the complete dependency set. - Review cycle: the first Apex review scored 3/5 with four findings. All were fixed together, the branch was rebased to resolve a schema conflict, full CI and standard Greptile passed, and a second Apex review returned 5/5 on `fda42c5ab` with zero new comments. All six review threads are resolved, and the PR is conflict-free. Review: https://github.com/paperclipai/paperclip/pull/17761#issuecomment-6422635718. - No live provider resource was created and no deployment was performed. ## Risks Plugins must opt in and ship a compatible declaration. Companies requiring hire approval keep drafts paused and defer allocation and verification until approval. Other companies prepare drafts during the wizard under their existing agent-creation authority; the setup hold still blocks ordinary work. Preparation uses existing lifecycle ownership, retry, and cleanup paths. The open wizard polls only while preparation or stopping is active. No database migration is required. ## Model Used OpenAI Codex, based on GPT-6, with reasoning, tool use, and code execution. The exact serving model ID and context window size are not exposed. ## 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 described the issue in-PR using the bug report fields - [x] I have not referenced internal or instance-local issues or links - [x] My branch name describes the change and contains no internal ticket id - [x] I have run the targeted tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation - [x] I have considered and documented the risks - [x] All Paperclip gates are green — 55 successful checks and two intentional skips on `fda42c5ab` - [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>	2026-10-26 15:21:47 -07:00
Nicky LeachandPaperclip	4ff493fb40	feat(plugins): include managed skills for selected environments (#17774 ) ## Thinking Path > - Paperclip manages agents and their execution environments. > - Plugins can vendor company skills and provide environments. > - Environment tools need their instructions before the provider starts. > - Persistent computers also need those skills before any run begins. > - This change adds environment requirements to normal skill selection and lifecycle synchronization. > - Plugin names prevent ambiguity, and required skills take delivery precedence without deleting company data. ## Linked Issues or Issue Description Problem or motivation An environment can provide desktop tools while its agent receives no instructions for those tools. A first-run-only import also leaves idle computers without required skills. Same-name company skills can make provider discovery ambiguous. Proposed solution Let plugin environment drivers declare their managed `skillKeys`. Install missing requirements during lifecycle reconciliation or new-run preparation. Deliver updates through the durable runtime event journal. Give managed imports stable plugin names and report shadowed assignments. Alternatives considered ROM links do not make a skill a normal Paperclip selection. Polling duplicates the existing lifecycle delivery queue. Replacing a same-name company record would destroy independent data and assignments. Roadmap alignment This extends the shipped Plugin system and Skills Manager. The existing related-PR search found no duplicate contract. ## What Changed - Validate `environmentDrivers[].skillKeys` as unique references to the same plugin's managed skills. Require a ready, enabled plugin with `skills.managed` authority. - Resolve company-scoped skills before version capture. Preserve explicit pins, company edits, and saved recovery selections. Serialize concurrent first installs. - Allow lifecycle callers to request missing-skill installation through `agents.getRuntime`. Ordinary task and recovery reads do not install new declarations. Pass task-selected environment IDs through the SDK. - Add SQL migration `0378_environment_skill_runtime_hooks`. Required skill edits, effective default changes, environment changes, and plugin requirement changes enqueue durable runtime events. Reuse lifecycle delivery and retries; add no polling. - Import managed defaults as `plugin-<short-plugin-id>-<skill-slug>`, including the SKILL.md name. Preserve canonical keys. Keep same-name company records separate without counter suffixes. - Required environment skills win delivery over same-name company assignments. Preserve saved assignments and library content. Record shadowed and winning keys in run warnings, run snapshots, and plugin runtime state. Removing the environment requirement restores the ordinary assignment. - Document the contract for `driver: "plugin"`. Other drivers and plugins without requirements keep existing behavior. Existing managed copies retain edits and names until reset. ## Verification - Latest targeted local checks: environment skills (5), managed skills (9), heartbeat execution configuration (27), and SDK worker RPC host (23): 65 tests passed (including the targeted schema-drift check). Disposable PostgreSQL exercised the migration, first install before any run, concurrent lifecycle reads, implicit edit events, inherited defaults, rollback, plugin requirement changes, shadowing, preserved records, version capture, and recovery. - Review follow-up also verifies case-insensitive/runtime-name aliases, recovery of a task-mentioned shadowed skill, preserved quoted/multiline YAML, and zero runtime events for repeated local-folder settings writes. - Migration numbering and safety checks passed. Whitespace and secret/PII scans passed. - Earlier targeted manifest validation passed (43 tests). No validator behavior changed in this follow-up. - Broad tests, typecheck, build and end-to-end verification passed in [GitHub CI](https://github.com/paperclipai/paperclip/actions/runs/40387647219) for current head `ce57f2a4d`. Greptile is 5/5 with no unresolved threads. The [commitperclip review check](https://github.com/paperclipai/paperclip/actions/runs/40387646208) also passed after restoring its required duplicate-search checkbox. - Earlier attempts found a SQL alias collision, an unparenthesized CASE expression, and fixture assumptions about bundled catalog rows and YAML quoting. These were corrected before the passing checks. The first broad CI run also exposed a schema-drift check that assumed every journal entry had a schema snapshot; it now reads the latest actual snapshot, so SQL-only migrations need no invented snapshot. A test callback replacement also affected an unrelated fixture; it was restored before the final passing execution-configuration suite. Sandbox runs could not start PostgreSQL; the reported database tests used local socket access. ## Risks - Apply migration 0378 before using the updated lifecycle contract. It adds trigger functions and event producers; it does not rewrite agent assignments or skill content. - Required environment skills take precedence over same-name assignments, including task-selected skills. Both library records remain. Run warnings identify omissions. - Company edits are preserved. Plugin upgrades do not reset installed content or rename existing copies. Explicit reset adopts current defaults. - Namespaced library slugs can be shared by distinct canonical records. Callers must use IDs or canonical keys when a slug is ambiguous. - No live provider request or deployment was performed. The downstream plugin must be built against this Core revision. Persistent-home synchronization retains its existing edit-conflict and retry behavior. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools, and code execution. The exact model identifier and context-window size are not exposed in this task context. ## Checklist - [x] Thinking path and issue description included - [x] Model and available capabilities recorded - [x] Roadmap and related PRs checked - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] Public references only; no internal issue IDs or instance URLs - [x] Targeted local tests pass; broad verification delegated to GitHub CI - [x] New behavior covered and documentation updated - [x] Current-head CI green and Greptile 5/5 with no unresolved comments --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-26 14:11:35 -07:00
DottaandPaperclip	9ae4c25e7e	perf(runner): reuse compatible protected provider packs (#17749 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Native Runner starts provider runtimes in remote execution environments. > - Sandbox images already contain qualified provider packs. > - Startup required the image pack to match the entire current app release manifest. > - An unrelated app commit could therefore cause pack verification, transfer, and installation again. > - This pull request selects protected packs by their provider interface and platform. > - The benefit is no extra pack probe, directory scan, version command, link, or upload on the compatible image path. ## Linked Issues or Issue Description What happened? Starting a remote task can reject a compatible image pack because its source revision or unrelated provider differs from the controller. Pack replacement added about 16 seconds in the investigated startup. Startup also repeated full content checks. Expected behavior Use an already qualified, protected pack when its selected provider interface and target platform are compatible. Keep the selected artifact identity for process launch and recovery. Steps to reproduce 1. Install a qualified provider pack in a sandbox image. 2. Start a controller built from another app commit. 3. Start a remote OpenCode task. The old complete-manifest comparison rejects the image pack even when the provider interface still works. Related repairs: #16493 reduced transfer cost. #17512 retained exact artifact authority during reattachment. This change preserves that recovery rule and changes fresh-launch pack selection. ## What Changed - Add explicit OpenCode and ACPX interface revisions to produced pack manifests. App Git SHAs and dependency pins remain provenance. - Read bounded protected-installation metadata in the existing final runner metadata query. Accept only root-owned paths that the execution user cannot write, including ancestors and manifest. Reject writable aliases. - Select and prepare the pack in server-owned environment setup before constructing the existing transport. Bind provider launch paths and digests from the selected installation. Save that identity for exact reattachment. - Keep full content verification for uploads, writable installations, and legacy packs. Reuse successful verification within one startup. Keep older attached runners compatible with the optional metadata request. - Seal image packs and document the one-time image refresh that enables reuse across later compatible releases. Keep selected ACPX agent qualification checks. ## Verification - Red/green regression: the old code rejects a protected pack from another app revision with `manifest mismatch`; the fixed path selects it without executing verification commands. - Native startup regression: select the installed pack's own Node digest with one existing runner metadata request and no pack verification or version commands. - Targeted pack, artifact, recovery, execution-driver, and Rust metadata tests pass. Incompatible interfaces/platforms, malformed identities, writable roots, path aliases, and exact reattachment are covered. - Final revision `91dc1676ff67bdbe5866c8586daac10240530cca`: workspace typecheck and build pass. All 53 current-head checks are successful, with no pending or failed checks. Greptile is 5/5 with no open findings. - The broad local `pnpm test:run` attempt reported a workspace-runtime conflict test failure; its isolated rerun passed. The broad run was stopped after that failure. Full CI now passes, including the server test shards. This is not a claim that the full local run passed. - Linux filesystem evidence: the production metadata functions read a real root-owned preinstalled pack as a non-root user in 16 microseconds median and 20 microseconds p95 across 100 warm reads. This measures metadata admission, not model or hosted response latency. - All 910 affected server tests and 57 Copilot attestation tests pass locally on the final implementation. Full CI covers the unchanged Runner transport. No provider qualification hash was refreshed. - Built the actual Linux daemon at `416e7ec7425d0d3565b4a5e1808002d650a60414` and ran its metadata command as UID 65534. The protected installation returned its real manifest with `immutable: true`; writable alias and missing-pack cases returned `immutable: false`. This is metadata/permission evidence, not provider execution. - Hosted rollout and a hosted end-to-end latency measurement have not run. ## Risks - Existing images need one rebuild to publish the compatibility declaration. Packs without it keep the legacy content-verification path. - Fast admission relies on image publication producing a qualified protected tree. Root execution and task-writable installations retain full verification. - Bump an interface revision when required runner/pack behavior changes incompatibly. Deploy a new image to roll out compatible runtime fixes or upgrades. - This removes provider-pack preparation delay. Other runner startup, context, model, and finalization costs remain separate. ## Model Used OpenAI Codex, configured model `gpt-6.1-sol`, reasoning effort `xhigh`, with tool use and code execution. The context-window size is not exposed in this session. ## 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>	2026-10-26 14:43:12 -05:00
DottaandPaperclip	5823e9a664	fix(runner): preserve disabled Codex web search (#17744 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Native Codex agents use the saved agent settings to prepare each provider launch. > - Onboarding saves web search as off, but native configuration conversion removes that setting. > - Codex 0.160.0 includes a hosted web-search tool by default, even in an authentication probe that asks it not to use tools. > - A gateway that permits only priced function tools can reject that request before budget admission. > - This change preserves the explicit restriction through native execution and disables web search for authentication probes. ## Linked Issues or Issue Description What happened? A native Codex authentication probe can include hosted web search. Normal task execution also loses a saved `search: false` setting. A restricted Responses gateway can reject these requests before it makes a model call. Related repairs: Refs #17445, Refs #17529. The roadmap and related PRs were checked; no duplicate repair was found. Expected behavior Authentication probes check the selected account and model without hosted web search. A saved search-off setting remains effective in native task launches, prepared launches, and session recovery. Existing behavior for an absent setting remains unchanged. Steps to reproduce 1. Create a Codex agent with search off and choose Paperclip Runner. 2. Use a Responses gateway that rejects hosted tools. 3. Inspect the request from the native authentication probe or task launch. Before this fix, the pinned Codex SDK includes `web_search` despite the saved setting. ## What Changed - Preserve an explicit search-off setting when native agent configuration is built and converted. - Carry the restriction in the durable native input and provider launch requirements. - Apply the restriction to authentication probes and normal launch paths, including custom arguments and recovery. - Reject prepared launches that discard the required restriction. Keep gateway billing rules unchanged. - Admit only the restrictive literal value in the strict plugin task API. Exercise the real plugin setup path. - Add regression coverage and document the policy. - Add the immutable Copilot v60 source identity required by the changed shared files. Preserve v59 and all original live evidence. Copilot authentication probes keep their prior launch requirements. ## Verification - Regression cases were run against the unfixed source and failed at the configuration and launch boundaries. - An isolated capture using the real Codex 0.160.0 app-server reproduced hosted-tool rejection. Disabling web search reached a mocked budget reservation. The helper and child processes permitted only loopback network access and used synthetic credentials. It made zero upstream calls. - Focused checks passed: 284 server cases, 61 native form cases, 198 backend/security/launch/parser cases, and 36 authentication/launch cases. A separate complete transport/launch/parser run passed 393 cases. These groups overlap. - Head `617b98f` passed workspace typecheck/build and 28/28 plugin contract and actual Runner probe tests with no skips. Final rebased head `20ff0c1` passed all current-head CI checks, including full isolated test lanes, and fresh Greptile and Paperclip reviews at 5/5. - The additive Copilot identity update passed 134 compatibility/policy/protocol checks and nine authentication probe checks. The real pinned Codex SDK capture was repeated after the final policy change: all five cases passed with zero upstream calls. - Two local full-suite attempts stopped after native PostgreSQL loader failures. Seven local dependency aliases were restored, and an isolated cluster initialized successfully. A third run later encountered host PostgreSQL semaphore exhaustion and was interrupted before source-profile regeneration. Its zero exit code after SIGINT is explicitly not a full-suite pass. Final full-suite verification runs in isolated CI; the local attempts remain recorded. - The first CI run exposed a missing strict plugin API field. Its five failures were reproduced locally, then passed after repair. The next run passed every underlying job except the source-identity guard. That guard now binds an additive identity with v59 retained. Final-head CI and both fresh reviews passed; addressed review threads are resolved. - The offline capture runs on Darwin ARM64. It does not prove the contents of a prior unretained Linux request or complete Cloud onboarding acceptance. ## Risks - The restriction must survive prepared launches and resumed sessions. Regression tests cover those boundaries. - Existing absent settings retain their prior behavior. This change does not add native search-on support or loosen gateway admission. - Older durable inputs without the optional restriction must remain valid. - Copilot now uses profile v60 for exact launch admission. Historical v59 inputs remain readable. The new declaration adds no live Copilot qualification and does not change its executable or admission flags. - A deployed Cloud acceptance run is still required after this source repair. ## Model Used - OpenAI GPT-6 through Codex, with reasoning, code execution, and delegated review. The exact backend model identifier and context-window size are not exposed in this session. ## 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>	2026-10-26 10:29:51 -05:00
Devin FoleyandPaperclip	b792165ba4	Expire native runner continuity archives and quarantine (#17616 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Native runner sessions keep durable state under `<instance>/runtime/paperclip-runner/durable-sessions/` > - When a session starts a fresh provider session, the retired state is moved into `<session>/continuity-breaks/<epoch>-<uuid>/`; when state loses authority, it is moved into `quarantine/<session>.<reason>.<epoch>.<pid>.<uuid>/` > - Nothing ever removes either, and each can hold a full Codex home of several gigabytes > - A sleep-aware sweep already expires failover backup copies in the same tree > - This pull request extends that sweep to remove both kinds of evidence after a retention window, while keeping anything recovery may still read > - The benefit is that native runner disk use stops growing without bound ## Linked Issues or Issue Description Bug report described in-PR (bug report template). What happened? On one instance, one day of native runs produced 20 continuity-break archives totaling 4.8 GB, one session alone holding 4 GB. The quarantine folder held 12 entries totaling 2.1 GB, the oldest a month old. Neither is read again by normal operation (continuity-break archives are written by `archiveContinuityState` and never read), and nothing deletes them. They were removed by hand to free space and will regrow. Expected behavior Evidence older than a bounded window is removed automatically, as failover backup copies already are, without removing anything a live session or recovery path still needs. Steps to reproduce 1. Run a native Codex session that hits a continuity break (fresh provider session), or whose state is quarantined (for example `identity_indeterminate`). 2. Inspect `durable-sessions/<session>/continuity-breaks/` and `durable-sessions/quarantine/`. 3. Wait any length of time: the entries stay forever. Paperclip version or commit: `master` at `e335265568`. Deployment mode: any with native runner sessions. Agent adapter(s) involved: native runner (Codex, and any provider whose state lands in these folders). ## What Changed - `server/src/services/native-runtime/native-harness-backup-expiration.ts`: the existing tick also retires evidence. - Continuity-break archives (`<epoch ms>-<uuid>` under each session): removed when older than the window. Age is the epoch in the name, or the folder mtime when that epoch is in the future. `archiveContinuityState` refuses to archive state with warm-transition evidence, and no code path reads `continuity-breaks`. - Quarantine entries (`<session>.<identity_indeterminate\|identity_mismatch>.<epoch ms>.<pid>.<uuid>`): removed by the same age rule. Native cleanup source archives (`<session>.identity_indeterminate.cleanup.<uuid>`) are referenced from recovery history, have no epoch, and keep their original inode's mtime, so they are always kept. - Every entry is skipped while its session is executing, initializing, warm, or closing in this process; this is checked again just before removal. Symlinked entries and symlinked `continuity-breaks`/`quarantine` folders are reported as `unsafe_path` and never followed. - Removal renames to `.expired-<uuid>` in the same folder and then deletes; later sweeps finish interrupted deletions. An empty `continuity-breaks` folder is removed. - Archives, quarantine entries, and leftover deletions count toward `maxEntries` and `maxRemovals`, and stop on `shouldContinue`. Paging resumes inside a session's archives and then in quarantine, so a bounded or dry-run batch always makes progress and never recounts a session's backup. - New result fields: `evidenceCandidates`, `evidenceCandidateBytes`, `evidenceRemoved`, `evidenceReclaimedBytes`, and skip reasons `recent_evidence` and `cleanup_archive`. The service also exposes `noteEvidence(writtenAt)`. - `server/src/services/native-runtime/native-runner-evidence-signal.ts` (new): a process-local signal. `native-session-executor.ts` raises it with the entry's epoch right after `archiveContinuityState` creates an archive and after `quarantineRunnerdStateRoot` moves state into quarantine; `server/src/index.ts` subscribes the sweep and unsubscribes on shutdown. - `server/src/config.ts`: `PAPERCLIP_NATIVE_RUNNER_EVIDENCE_RETENTION_DAYS` (default `7`, minimum `1`). - `server/src/index.ts`: passes the window and logs a batch when it found evidence candidates. - `doc/recoverable-disk-cleanup.md`, `doc/DEVELOPING.md`: document the variable and behavior. Sleep-aware background work (`rules/sleep-aware-background-work.mdc`): - Trigger: each entry's own expiry deadline (its epoch plus the window), plus a direct call from the executor when it writes new evidence. No timer, interval, or polling loop is added; the pass runs inside the existing sweep's tick and keeps its drain, warm-standby, and shutdown handling. - Source of truth: the filesystem entries themselves. After a restart the first sweep reconstructs the next deadline from them. - Pending-work predicate / next deadline: after a full pass the sweep keeps the earliest due time of the entries it retained; ticks before that time skip the evidence pass entirely (no readdir, no SQL). A busy session, a failed removal, or a full batch makes it due on the next sweep while that obligation remains. - Quiet condition: no evidence, or only evidence not yet due. The pass never queries the database, so retained evidence never causes recurring SQL. Dry run reports each candidate once rather than every hour. No code comments were added. ## Verification - `pnpm exec vitest run src/__tests__/native-harness-backup-expiration` (in `server/`, embedded Postgres): 52 passed. New cases: - old archives and quarantine entries are removed, recent ones kept; the empty `continuity-breaks` folder is removed; - age comes from the name, with mtime used for a future epoch; non-archive folders are ignored; - a busy session keeps its evidence, including when it becomes busy after the first check, and it is retried on the next tick; - dry run reports candidates and bytes, changes nothing (including leftovers), and reports each candidate once until new evidence comes due; - symlinked entries and symlinked evidence folders are skipped without touching the target; - an old quarantine entry is removed even when its session's issue is still open; cleanup source archives are kept; - the pass stays quiet until retained evidence is due, and a `noteEvidence` signal schedules newly written evidence; - inspected archives and leftovers count against `maxEntries`, and leftover removal stops on `shouldContinue` and resumes next tick; - a due pass stopped by drain before any session stays pending; one-entry batches finish without recounting a resumed session; - interrupted `.expired-` deletions are finished; paging across ticks with `maxRemovals`, in normal and dry run, with no recount of the backup when resuming. - `native-session-executor.test.ts`: quarantining a legacy root raises the evidence signal with the epoch in the entry name. - `native-harness-backup-expiration-config`: default, explicit, minimum, and fallback parsing. - Mutation checks, each failing at least one test: removing the age check, the future-epoch fallback, either busy check, the busy retry deadline, the recent-entry deadline, the due gate, the `noteEvidence` update, merging the pass deadline, the entry and both folder symlink checks, the dry-run return, the dry-run leftover guard, leftover removal, the leftover budget check and its retry deadline, counting archives against `maxEntries`, the cleanup-archive skip, the empty-folder removal, the resume cursor, the per-archive budget check, the resume skip of the backup pass, not charging a resumed session, keeping the pass active across drain, and the executor's quarantine signal. - `pnpm exec vitest run config native-harness native-workspace-sync-retention native-session-executor server-startup` (in `server/`): 1272 passed on the previous commit; `config native-harness native-workspace-sync-retention server-startup`: 450 passed on the head commit. - `pnpm run typecheck` (in `server/`): pass. - Not run: server build and boot smoke. The continuity-archive signal call is exercised only by a runner integration test that needs the runnerd binary. ## Risks - Quarantine as a fail-closed fence:* recovery (`recoverQuiescentRunnerdState`) and failed-run retry (`nativeFailedRunRetryStateIsSafe`) treat a quarantined entry for a session as a reason not to bootstrap fresh. Once such an entry ages out, a later run of that session can start a fresh provider session instead of failing with `quarantine_owner_unverified`. This applies only after the window, matching what backup expiry already accepts for closed work. - Signal coverage: the signal is process-local. Evidence written by another process sharing the same state directory is picked up when the next retained deadline is due or after a restart, not immediately. - Legacy-path quarantine: entries quarantined from legacy roots carry a legacy digest, so the in-process busy check cannot match them; they are removed by age only. - Remote sandboxes: archives moved aside on a remote runner (`<root>.continuity-break-<token>`) are outside this sweep. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file edits, tests). ## 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>	2026-10-25 09:20:30 -07:00
Devin FoleyandPaperclip	50797ea03c	perf(issues): narrow queued comment wake display reads (#17570 ) Read only typed queue display inputs from saved wake payloads and only runtime mode from queued runs. Preserve complete rows for locked edits, discard, steering, and interruption. Validation: 93 focused route and policy tests, full build and repository typecheck. PostgreSQL fixtures preserve identical queue responses and saved input with less than 4 KB of read values; restoring the full wake read fails at about 1.8 MB. Exact-head Greptile 5/5 (medium), all CI checks green, and zero unresolved comments. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-25 00:41:14 -07:00
Devin FoleyandPaperclip	7494b8dd4c	perf(auth): batch current run history read decisions (#17569 ) Reuse the existing authorization batch owner for current run-history read decisions after company-scoped existence checks. Preserve missing-task denial, per-request freshness, and the decide-only adapter path. Validation: 97 focused tests, full build and repository typecheck. A real PostgreSQL fixture returns identical decisions with 4 queries instead of 327; the original path fails the query-bound regression. Exact-head Greptile 5/5 (medium), all CI checks green, and no unresolved comments. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-25 00:35:07 -07:00
Devin FoleyandPaperclip	f978a521ff	perf(heartbeat): narrow workspace operation access reads (#17565 ) Read only the current run access fields and typed workspace binding for workspace-operation polling. Keep the current privacy decisions, operation checks, and complete run storage. Verified focused run-state, live-event, and real database privacy-route tests, full build and typecheck, all CI checks, and exact-head Greptile 5/5 with no unresolved threads. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-25 00:21:15 -07:00
Devin FoleyandPaperclip	1ad8f25c77	perf(heartbeat): narrow queued comment polling run reads (#17560 ) Read current control facts and typed issue/adapter bindings for queued-comment polling. Keep full mutation and execution reads, native preparation and steering, authorization, and stored evidence. Validation: full build and typecheck, 160 focused tests plus two assembled route regressions; exact-head Greptile 5/5 (medium), full green CI, zero unresolved threads. Old-route counterfactual transfers 2.5 MB versus less than 2 KB. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-24 23:53:39 -07:00
Devin FoleyandPaperclip	a7006a9506	Reclaim finished isolated task directories with restore points (#17472 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents do task work in execution workspaces on the instance disk > - A task without a project repository runs in a plain (non-Git) task directory under `<instance>/isolated-workspaces/<company>/<issue>/` > - Nothing removes these directories after the work is done, so the disk fills up > - The directories can hold the only copy of agent work, so plain deletion is not safe > - This pull request saves each finished task directory in an encrypted restore point, removes it, and restores it when the work reopens. It also removes orphaned directories after a grace period > - The benefit is that finished task directories stop using disk, and no agent work is lost silently ## Linked Issues or Issue Description What happened? On one instance, `instances/<id>/isolated-workspaces/` held 251 task directories and 12 GB, and it grew every day. 61 directories belonged to open workspace rows whose issues closed more than 7 days before (3.9 GB). 12 belonged to issues closed 3 to 7 days before (0.7 GB). 4.0 GB were directories with no open workspace row (the row was archived or missing). The cause has two parts: 1. The terminal workspace reaper archives a workspace only when it proves delivery through Git (a merged pull request or a merged branch). A task directory is not a Git checkout, so the Git status inspection fails and the reaper always skips the row as "undelivered". Git cache expiration handles only `git_worktree` workspaces. 2. When a person archives such a workspace by hand, artifact cleanup removes a `local_fs` directory only when `metadata.createdByRuntime` is true. Task directory rows never set it, so the directory stays and the row becomes `cleanup_failed`. Expected behavior Paperclip reclaims the task directories of finished work by itself. It must not lose files that only exist in those directories. Steps to reproduce 1. Run an agent on an issue without a project repository (for example a low-trust sandbox task, or an issue with no project), so it works in `isolated-workspaces/<company>/<issue>/`. 2. Let the agent write files there, then mark the issue `done`. 3. Wait any number of days. The directory and its workspace row stay. The reaper logs the row as skipped (undelivered). 4. Archive the workspace by hand. The directory still stays. Paperclip version or commit `master` at `fe85fd7ac4` Deployment mode Self-hosted, local disk storage. Agent adapter(s) involved Any adapter that runs in a task directory (seen with local and sandbox runs). ## What Changed - Added `isolated-task-directory-snapshot.ts`: a deterministic snapshot of a plain directory (files with modes, directories, symbolic links as links). It never follows symbolic links, refuses special files, and enforces the restore point limits (20,000 files, 64 MiB per file, 256 MiB in total). A `node_modules` directory next to a `package.json` is left out. Restore writes to a staging directory, verifies the digest, then renames it into place. - Added `isolated-task-directory-retention.ts`: - `expireIsolatedTaskDirectory` saves the directory in a restore point, archives the workspace with the `isolatedTaskDirectoryRetention` state in one transaction, checks again that the directory did not change, renames it to trash and deletes it. A change after the capture rolls the workspace back to active and drops the restore point. An interrupted removal finishes on a later sweep. - It uses the git cache expiration consumer checks (`isGitWorkspaceExpirationEligible`): no live run, unsettled finalization, live lease, live runtime service, unresolved recovery action or reopen fence, and no other open workspace or project workspace in the directory. It also requires the source issue to be bound to the workspace, because reopen restores through that binding. - `restoreIsolatedTaskDirectory` restores the directory on reopen. It replaces an empty directory and fails closed on a non-empty directory that does not match. When the restore point expired, it reopens an empty directory and posts a system comment. - `sweepIsolatedTaskDirectories` walks `isolated-workspaces/` in bounded batches (8 per sweep, with a cursor). A closed workspace that its issue is still bound to is saved and removed like an open one. Other folders are orphans and are removed after a grace period when no live row, project workspace, runtime service, run, finalization, lease or recovery action refers to them. - Reused the git restore point ledger, storage and encryption. `storeSealedRestorePoint` and `readRestorePointObject` were extracted from `storeGitRestorePoint`. `markGitRestorePointExpired` now also marks a task directory restore point as expired. - `isGitWorkspaceExpirationEligible` takes `closedSiblingsAllowed`, so closed rows for the same issue directory do not block a task directory forever. Git expiration keeps its old behavior. - Terminal workspace reaper (`execution-workspaces.ts`): handles open task directory rows after the terminal delay and registers that moment as a deadline. It finishes pending removals, runs the folder walk at the start of a rotation (once per server start, then only at real deadlines), and saves at most 8 directories per sweep. - Reopen accepts a closed `shared_workspace` row that holds task directory state. The run path also reopens (and restores) a closed workspace with that state before preparing the run. - Settings: `PAPERCLIP_TASK_DIRECTORY_RETENTION_ENABLED` (default `false`), `PAPERCLIP_TASK_DIRECTORY_RETENTION_DRY_RUN` (default `true`), `PAPERCLIP_TASK_DIRECTORY_ORPHAN_GRACE_DAYS` (default `7`, minimum `1`). The delay is `PAPERCLIP_GIT_RESTORE_POINT_TERMINAL_DELAY_DAYS`. Removal needs `PAPERCLIP_GIT_RESTORE_POINTS_ENABLED=true`. - Logs: `execution_workspace.task_directory_retention`, `execution_workspace.task_directory_cleanup` and `execution_workspace.task_directory_restore`, with outcome, skip reason, candidate bytes and reclaimed bytes. - Documented the behavior in `doc/recoverable-disk-cleanup.md` and the settings in `doc/DEVELOPING.md`. Preservation decision. The code shows that these directories are not scratch space. Nothing pushes or copies their contents, and the next run of the same issue reuses the same path. So the files are saved before removal, with the same ledger, encryption and retention as git restore points, and restored on reopen. Orphans are not saved: no workspace row can reopen them. The docs and the Risks section state this. Scheduling. The work follows `rules/sleep-aware-background-work.mdc`. It adds no timer and no polling. Open rows use the existing reaper and its per-workspace deadlines (the end of the terminal delay, or one hour after a retryable skip). The folder walk runs once at startup. After that, workspace archive and issue close notifications (the existing terminal workspace hints) point the reaper at the affected folder, and a kept folder is checked again only at its own deadline (end of a grace period or terminal delay, or one hour after a busy lock or live consumer). When the tracked state is full, the reaper schedules another walk instead of dropping work. With nothing pending, it registers nothing. ## Verification - `cd server && pnpm exec vitest run src/__tests__/isolated-task-directory-retention.test.ts src/__tests__/isolated-task-directory-retention-config.test.ts src/__tests__/heartbeat-task-directory-restore.test.ts` (embedded Postgres): 48 tests pass. They cover: - a closed issue's task directory is archived and removed after the delay by the reaper, and reopen restores files, modes and symbolic links exactly; - the same through reopen for a `shared_workspace` row, and through a real heartbeat run (the run restores the files and runs in them); - the directory stays before the delay (and the deadline is the end of the delay), while the issue is open, and when retention is off; - the directory stays while each consumer check fails: live run, live runtime service, reopen fence, unsettled finalization, live lease, unresolved recovery action, issue bound elsewhere, live sibling workspace in the directory; - no removal without restore points, with a non-durable key, before `notBefore`, or over the limits; - dry run changes nothing; a change after the capture rolls back; an interrupted removal finishes on the next sweep; an expired restore point reopens empty with a warning; a diverged directory fails the reopen and stays untouched; - folder sweep: an orphan is removed after the grace period, kept when recently modified, in dry run, when a live row points into it, and when its issue is open; an archived unbound row's folder is removed; an archived bound row's folder is saved, removed and restored on reopen; the walk is bounded and continues from its cursor; - review follow-ups: a file name with a backslash saves and restores; after the startup walk, a workspace archived later is found through its change hint; an orphan used by a live run is retried; skipped rows do not starve later rows of the per-sweep budget; overflowing tracked deadlines schedule another walk instead of being dropped; a closing child sends the reaper back to its archived parent's folder; a pending lease cleanup on a closed workspace keeps an orphan; a deep path at the platform path limit restores; an expiry recorded during removal survives and the archive and removal are recorded as activity; a task closed beyond retention keeps its new restore point for the full period; - symbolic links: a task directory that is a link, an orphan that is a link, and a link inside a directory are never followed; the link targets stay untouched. - Mutation checks. Each change below made at least one of the tests above fail, and the test passed again after revert: - drop the run-path reopen condition; drop the skipped-row cache; drop hint tracking; reject backslashes again; drop the live-consumer retry for folders; evict overflowing folder deadlines; skip ancestor hints; ignore workspace-attached leases for orphans; stage restores under the old longer name; overwrite the whole metadata on the final write; retain task directory restore points from the tree close only; drop the removal activity; force `closedSiblingsAllowed` off; make live siblings not block; skip the digest recheck before rename; skip the issue binding check; remove both symbolic link refusals (task directory); remove the orphan symbolic link refusal; ignore live rows in the folder walk; skip the orphan modification grace; ignore dry run for orphans; skip the restore on reopen; skip the terminal delay; skip the restore points requirement; skip the orphan open-issue check. - Removing only one of the two task directory symbolic link checks did not fail a test, because the other check still refuses the link. Removing both fails the test. - Related suites: `pnpm exec vitest run execution-workspaces isolated-task-directory workspace-runtime git-restore-point git-workspace-expiration terminal-workspace workspace-reaper heartbeat-git-restore heartbeat-task-directory isolated-repository-rehome nested-clone-migration environment-selection` in `server/`: 34 files, 749 tests pass, 4 skipped. Two `workspace-runtime.test.ts` tests fail (`does not diagnose a missing remote branch as a rejected credential`, `rejects explicit main on a master-only remote ...`). They fail the same way on unchanged `master` on the local machine, so they are not caused by this change. - `pnpm run typecheck` in `server/`: passes. - Not run: the full server suite, a live instance rollout, and a check that the host disk usage drops after removal. ## Risks - The feature is off by default, and it starts as a dry run when enabled. It needs restore points to remove anything. Rollback: set `PAPERCLIP_TASK_DIRECTORY_RETENTION_ENABLED=false`. Saved restore points and restore on reopen keep working. - Orphan folders are removed without a restore point. This applies only when no workspace row is bound to the issue at that path. If such an issue is reopened later without another workspace, its next run starts in an empty directory. The grace period (default 7 days of a closed tree and no changes) and the dry run limit this risk. - A directory over the restore point limits stays on disk (logged with its reason). Special files keep a directory too. - `node_modules` next to a `package.json` is not saved. A reopened task must install its packages again. - The restore point lives as long as git restore points (90 days by default), counted from the later of the tree close and the removal. Only task directory restore points use the removal time; git restore points keep their retention. After that, reopen starts with an empty directory and posts a warning comment. - Reopen now accepts a closed `shared_workspace` row, but only when it holds task directory state written by this feature. - No schema migration. The ledger table and its columns are unchanged. > 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 - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-24 14:16:58 -07:00
Devin FoleyandPaperclip	fe85fd7ac4	Expire closed workspaces that open descendants do not use (#17464 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Git cache expiration removes closed issues' worktrees and saves restore points for unsaved work > - It treated a workspace as closed only when the source issue and every descendant were done or cancelled > - A routine that closes a parent and leaves children open for days therefore kept every parent worktree, although the children work in their own workspaces > - The idle path did not help, because the children are updated every day > - This pull request counts only the issues that use the workspace when it decides that a closed workspace can expire > - The benefit is that closed parent worktrees are removed while their children work elsewhere, and a child that later binds to the workspace gets it back from the restore point ## Linked Issues or Issue Description Refs #17271. Bug report described in-PR (bug report template). What happened? On one instance, an hourly routine creates a parent issue, works it in its own worktree, marks the parent done, and leaves child issues open (`blocked`, `in_review` or `in_progress`) for days. The children work in their own workspaces. They are not bound to the parent's workspace. Git cache expiration kept every parent worktree (about 300 MB each), because the closed-tree check and the workspace reaper required all descendants to be closed. In one project, 18 of 19 long-closed parent worktrees were kept only by open children that did not use them. The idle path never ran, because the children were updated daily. Expected behavior A closed issue's worktree expires while descendants are open, as long as no open descendant uses that workspace. Steps to reproduce 1. Enable git cache expiration and restore points. 2. Close an issue that has an isolated git worktree, and leave a child issue open that works in its own workspace (or has no workspace binding). 3. Wait past the terminal delay and run the workspace reaper: the parent worktree stays, and the reaper counts it as `skippedNonTerminalTree`. Paperclip version or commit: `master` at `410e5c6eed`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). ## What Changed - `isGitWorkspaceExpirationEligible` (closed path, not the idle path): the "tree closed for one day" check now covers only the issues in the tree that use the workspace. An issue uses the workspace when it is the source issue, when its `execution_workspace_id` is the workspace, or when its current `workspace_selection` or its `workspace_pending_selection` selects it as the `existing` workspace. Inheritance from a parent (`reuse_existing`) and `existing` selections are both stored as `execution_workspace_id`, and heartbeat workspace resolution reuses an existing workspace only through that binding or a run's persisted native binding. An open descendant without one of these references gets a new workspace on its next run, so it no longer keeps the parent's worktree. - All other checks stay the same: any open issue bound to the workspace, live or unsettled runs of any issue in the tree or of the workspace (including a run whose context names the workspace), finalizations, leases, recovery actions, runtime services, shared cwd and the reopen fence. - Workspace reaper: when the source issue is closed, git cache expiration applies, and no reopen is pending, the reaper routes the workspace by the same rule. It takes the restore point due time from the source issue and the descendants that use the workspace, also after every descendant is closed. A recently closed child that used the workspace still holds it for the terminal delay. The compaction delay and the archive cooldown still use the whole tree when it is closed. - Workspace reaper: compaction and the normal archive path keep their behavior. While any descendant is open, the reaper does not compact the worktree, and the expiration branch handles the workspace and continues. The archive path still requires a closed subtree. With expiration off, or a pending reopen, routing is unchanged. - New exported helper `listIssuesUsingGitWorkspace` shares the SQL "uses the workspace" predicate between eligibility and the reaper. - Docs: `doc/recoverable-disk-cleanup.md` and the `PAPERCLIP_GIT_RESTORE_POINT_TERMINAL_DELAY_DAYS` entry in `doc/DEVELOPING.md`. - The existing `preserves live descendants and pending reopening` case now binds its open child to the workspace. An unbound open child no longer keeps the worktree by design. ## Verification - `pnpm exec vitest run src/__tests__/git-restore-point-expiration.test.ts src/__tests__/git-workspace-expiration.test.ts src/__tests__/heartbeat-git-restore-point-resume.test.ts` in `server/`: all pass. - `pnpm exec vitest run src/__tests__/git-workspace-expiration src/__tests__/git-restore-point src/__tests__/execution-workspace src/__tests__/heartbeat-git-restore-point-resume src/services/heartbeat/environment-selection src/__tests__/isolated-repository` in `server/`: 15 of 17 files passed in one parallel run. The other failures were the updated descendant case (now fixed) and 45-second timeouts in restore point tests while 17 embedded Postgres files ran at the same time. Both files pass when run on their own. - `pnpm run typecheck` in `server/`: passes. - New embedded Postgres cases with real git repositories: - A closed parent with open `blocked`, `in_review`, `in_progress` and `todo` children and a grandchild in their own workspaces (or with none): the worktree expires with a restore point and the reopen restores it exactly. - The reaper archives it, timed from the issues that use the workspace. A child closed one minute ago with its own workspace does not delay it. - A recently closed child bound to the workspace holds it until its terminal delay passes. - When every child is closed and the most recent one used its own workspace, the reaper does not restart the restore point delay. - The worktree is kept when an open child is bound to it, when an open grandchild under a child with its own workspace is bound to it, when a child created later with `issueService.create` inherits it with `reuse_existing`, when an open child selects it through `workspace_selection` or `workspace_pending_selection`, when a child run that references it is live, and when the parent was closed inside the delay. - The reaper never compacts the worktree while children are open, with expiration on or off. A pending reopen keeps its current fence handling. - After expiry, an open child that binds to the workspace reopens it with the saved commits, index, working tree and untracked files. - Heartbeat: a queued run for an open child that binds to the expired workspace of a closed parent restores the workspace and runs the agent in it with the saved state. - Mutation checks (each run against the two restore point test files): - Closed-tree check restored to the whole tree: 7 tests fail. - `execution_workspace_id` removed from the rule: 3 fail. - `workspace_selection` removed from the rule: 1 fails. - `workspace_pending_selection` removed from the rule: 1 fails. - Reaper `latestTerminalAt` from the whole tree: 3 fail. - Reaper routing by the whole tree: 2 fail. - Reaper restore point due time from the whole tree once it is closed: 1 fails. - Pending-reopen gate removed: 1 fails. - Compaction gate (`!treeOpen`) removed: no test fails. Compaction's own guard under the lifecycle lock still rejects open trees, so the gate only skips work that cannot succeed. - Not run: the full server suite and the UI suites. CI covers them. ## Risks - Closed parent worktrees now expire while their children are open. A child that later binds to the workspace depends on the restore point and on the run-side reopen from #17271. The new tests cover this path. When restore points are off, only exactly reproducible worktrees expire. - An open child with no workspace binding no longer keeps the parent's worktree. Heartbeat resolution never reuses a workspace without a binding, so this does not change where the child runs. - The rule is conservative. A workspace selected only by an issue's current or pending selection is kept, and live runs of any issue in the tree still block. - The reaper runs one extra indexed query for each closed workspace when git cache expiration applies. No migration. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use. ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-24 12:43:57 -07:00
Nicky Leach	60ca3a903a	Keep warm sessions across project revision transitions (#17461 )	2026-10-24 12:11:26 -07:00
Devin FoleyandPaperclip	14e1f59fbf	fix(heartbeat): avoid large run reads during deferred-message recovery (#17460 ) ## Thinking Path > - Paperclip manages AI agents and their tasks. > - Deferred messages must survive restarts and execution cleanup. > - Periodic recovery checks the latest run before it attempts release. > - That check and two release checks load large execution records. > - These checks use only admission evidence and completion identity. > - This change selects those fields while keeping the release policy and fresh reads. > - Full execution records remain available for execution and detail reads. ## Linked Issues or Issue Description What happened? Deferred-message recovery repeatedly transfers stored context, Runner profiles, and output excerpts to make small admission and release decisions. Expected behavior Select the fields each decision consumes. Preserve queued messages, current admission checks, cleanup ownership, and fresh completion reads. Steps to reproduce 1. Save a terminal run with large context, profile, and output fields. 2. Leave an accepted message deferred after the issue lock is released. 3. Call `resumeQueuedRuns` and follow execution release. 4. Observe full-row reads before the admission decision. Paperclip version or commit Baseline: `410e5c6eedb`. Related read optimization: Refs #17405. Searched open and closed PRs for run projections and stranded-queue reads. Searched open issues for database transfer. No matching fix was found. Deployment mode External PostgreSQL. The regression tests use disposable real PostgreSQL. ## What Changed - Select seven admission fields for the stranded queue's latest-run lookup. - Select authentication classification evidence before execution release. - Read completion status and typed issue identifiers after post-commit effects. - Keep company scoping on both release reads. - Add large-payload and fresh-state regressions. Document the read contract. ## Verification - Focused PostgreSQL tests: 68 passed across queue, run control, and the new release-read suite. - Release reads return less than 2 KiB with three large synthetic execution fields. - Queue recovery passes less than 512 bytes to release, retaining the full stored message. - Coverage includes legacy/native owners, paused recipients, live successors, authentication repair, and fresh completion identity after post-commit effects. - Root recursive typecheck and full build pass. The full local stable suite remains in progress; no local full-suite pass is claimed. - All current-head CI checks pass on `c819fbb6b46bd5480a197407f06e02f245667792`. Greptile: 5/5, medium impact, zero comments and zero unresolved threads on that head. - The first focused attempt found a syntax error in the new test; it was corrected before the 68-test passing run. A redundant standalone compiler was stopped while the required recursive check continued. - Hosted impact is not measured yet. Staging verification follows merge. ## Risks The projection must retain all admission evidence and preserve JSON types. The release policy still owns transactions, locks, cleanup, and promotion. There is no schema migration, polling change, message deletion, or API change. Configuration repair evidence is read directly, including when unrelated result output is large. ## Model Used OpenAI GPT-6 through Codex, with source inspection, code execution, and GitHub tools. The exact served model ID and context-window size are not exposed in this session. ## 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>	2026-10-24 12:07:45 -07:00
Devin FoleyandPaperclip	1a79522a4e	perf: narrow run-to-issue authorization reads (#17405 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Run pages show links to issues associated with a run. > - The issue-link route checks the run's company and issue visibility before it reads those links. > - That check needs four binding fields, but the route reads the full run. > - Full runs can include large prompt, output, and result fields. > - This pull request uses the existing narrow authorization read. > - The route transfers less database data and keeps its permission checks and response contract. ## Linked Issues or Issue Description Problem or motivation `GET /api/heartbeat-runs/:runId/issues` calls `heartbeat.getRun` for a permission check. Its consumers only need the run ID, company ID, scope kind, and issue ID. The full read also fetches context, output excerpts, result data, and runtime metadata. Repeated link reads pay for that unused data. Proposed solution Use `getRunReadAccess`, the existing four-field read from #17348. Keep authentication, company access, company-scope authorization, run issue visibility, and linked-issue filtering in their current owners. Keep the existing empty response for missing and inaccessible runs. Alternatives considered A new query contract is unnecessary because the existing read provides all required fields. A permission cache could become stale. Changing the full run reader could affect consumers that need run details. Roadmap alignment This is a focused improvement to an existing route. It adds no feature, route, provider, cache, or background work. Searches for run-issue links, narrow run authorization, and `getRunReadAccess` found no open duplicate. Related work: #17348. ## What Changed - Change the issue-link route to use the existing narrow run read. - Reject full run reads in the route tests. Cover readable company and issue scopes, denied issue access, missing bindings, anonymous requests, and the missing/cross-company empty response. - Add a developer note about the read contract. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/activity-routes.test.ts src/services/heartbeat/run-state.test.ts src/__tests__/agent-live-run-routes.test.ts`: 126 tests passed. - `pnpm build`: passed. - `pnpm -r typecheck`: passed. - The route tests use the real run visibility helper with only the four binding fields. The full reader throws if a route calls it. The existing run-state suite checks the exact four-column selection and covers database wiring with disposable Postgres. - `git diff --check`: passed. Reviewed the committed diff for secrets and private identifiers before push. - Apex review: 5/5 on exact head `888a4ce9ea88bb2b284eb5e28fafc01b6f48b386`, completed successfully, with zero review threads. - Full current-head CI passed: 54 successful checks and two expected skips. [Workflow attempt 2](https://github.com/paperclipai/paperclip/actions/runs/40051399577/attempts/2). [Initial serialized shard failure](https://github.com/paperclipai/paperclip/actions/runs/40051399577/job/120744710081): the first company-history case in unchanged `agent-live-run-routes.test.ts` hit its 15-second timeout; the shard had 391 passing tests and one failure. That file, its agent route, the heartbeat state reader, and the service export are unchanged from base. The five company-history cases pass on unchanged base `9fb28d06ffebbb615f413765078aeeb7c4291311` (9.12s suite) and this head (8.29s suite). They also passed in the 126-test focused run. The timeout was not reproduced locally; its cause is not established. Only the failed shard was retried on the same head. It passed in attempt 2. This establishes recovery; the initial timeout remains in this record and its cause is unproven. - The prior local full-suite failures and baseline triage remain documented in #17384. No new local full-suite pass is claimed here. This change uses focused local tests and the full current-head CI gate. - No hosted user journey, staging deployment, production deployment, or billed savings is claimed for this follow-up. ## Risks - Run visibility depends on the canonical `scopeKind` and `issueId`. The existing helper returns those same fields. It does not use prompt or result data for access decisions. - Linked issues still pass the existing SQL visibility filter. Missing and cross-company runs still return `200 []`. Anonymous requests still fail before the run read. - The database query count stays the same. The change reduces data selected for this authorization read. - No schema or API response changes. ## Model Used OpenAI Codex, GPT-6 family. The exact deployment model ID and context window are not exposed in this session. Used reasoning, repository tools, and code execution. ## 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>	2026-10-23 19:59:21 -07:00
Devin FoleyandPaperclip	70de7d49e9	Migrate standalone nested clones onto the shared project clone (#17407 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Each task runs in a git worktree. Extra project repositories sit in the task under `.paperclip-repositories/`. > - #17382 made new nested checkouts git worktrees of one shared clone per project repository. Existing standalone nested clones stayed as full clones. > - Long-lived tasks keep those clones for a long time. Many tasks hold the same large repository, so most of the disk is duplicate `.git` data. > - #17369 added a locked and verified move of isolated workspaces onto the shared clone, with a reaper sweep behind a setting. > - This pull request adds the same kind of locked and verified conversion for standalone nested clones in open tasks, and runs it from the same reaper path behind a new setting. > - The benefit is that the duplicate clones go away without losing any state or local history, and the disk stops filling. ## Linked Issues or Issue Description Refs #17382 #17369. Bug report described in-PR (bug report template). What happened? On one instance, 44 open task worktrees in one project each hold a standalone nested clone of the same large repository. Together they use about 25 GB. About 16 GB of that is duplicate `.git` data. Another project has 33 smaller clones. The clones are removed only when their tasks expire, and many tasks stay open for a long time. The disk keeps filling. Expected behavior Existing standalone nested clones in open tasks become worktrees of the project's shared clone, with the same state and local history, and the standalone clones are deleted. Steps to reproduce 1. Prepare a task with a nested project repository before #17382, or without a shared clone, so that `.paperclip-repositories/<name>` is a standalone clone. 2. Create the project's shared clone, as #17382 does for new tasks. 3. Observe that the old checkout stays a full clone until the task expires. Paperclip version or commit: `master` at `8549ecaf9a`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). ## What Changed - New `server/src/services/nested-clone-migration.ts`. It converts one standalone nested clone in an open execution workspace into a worktree of the shared clone: - It holds the source lock and workspace lifecycle lock (as git cache expiration does), the per-shared-clone lock from #17382, and the expiration lock files (`index.lock`, `HEAD.lock`, current branch ref lock) in the clone. - It requires the #17369 no-live-consumer eligibility (no live runs, leased finalizations, unreleased leases, running services, or reopen flag). It checks again before the swap. - It identifies the repository by managed checkout name, project workspace rows and the origin URL, and it requires a verified shared clone. - It brings local history into the shared clone under the checkout's own `paperclip/<id>/` prefix. The current branch becomes `paperclip/<id>/<branch>`, tracking `origin/<branch>`. Unpushed local branches become `paperclip/<id>/<branch>`. Unpushed tags become `paperclip/<id>/tags/<tag>`. A restore point carries the commits, the `HEAD` reflog and `ORIG_HEAD`. - It stages the worktree at `<name>.clone-migrating`, applies the restore point, copies the `HEAD` reflog and `ORIG_HEAD`, and moves regenerable dirs, untracked `.env` files and `.claude/settings.local.json` by rename. Old and new must then match exactly (snapshot, history, branch, created refs, moved items). - Swap: it renames the clone to `<name>.clone-standalone`, runs `git worktree move` and `git worktree repair`, updates a saved restoration recipe that lists the checkout, and then renames the old clone to trash and deletes it. - A `nestedCloneMigrationPending.<name>` metadata record makes recovery possible. A crash before the swap rolls back (moves items back, removes the staged worktree and the created branches). A crash after the swap rolls forward. - Skip reasons (nothing changes): `live_or_unresolved_consumer`, `unknown_managed_checkout`, `local_source_checkout`, `foreign_origin`, `no_shared_base`, `shared_base_repo_mismatch`, `unsupported_base_git_config`, `nested_clone_has_stash` (stashes are skipped, because `refs/stash` would be shared by every worktree), `nested_clone_has_worktrees`, `nested_clone_has_hooks`, `unsupported_local_git_config`, `unsupported_local_git_state`, `unsupported_info_exclude`, `unsupported_nested_clone_refs`, `unsupported_index_flags`, `unique_branch_reflog_commits`, `nested_clone_ref_conflict`, `snapshot_mismatch`, `history_mismatch`, restore point limits, and `nested_migration_recovery_conflict`. - Reaper: `sweepTerminalWorkspaces` runs the conversion for open workspaces when `PAPERCLIP_NESTED_CLONE_MIGRATION_ENABLED=true` (default off). `PAPERCLIP_NESTED_CLONE_MIGRATION_DRY_RUN=true` only reports. Each attempt logs `event: "execution_workspace.nested_clone_migration"` with outcome, reason, branch, candidate bytes and reclaimed bytes. There is no new timer. A retry deadline is registered on the existing reaper deadlines only for a pending record or a transient skip (live consumer, busy lock, changed row). A workspace is attempted again at most hourly. A workspace without standalone clones costs one directory listing. - `isolated-repository-rehome.ts`: I exported the shared pieces (eligibility, locks, safe base config check, transfer plan, history boundary, snapshot and history keys, item moves, rollback and verification) instead of copying them. Re-home behavior does not change. - `nested-repository-worktrees.ts`: I exported the stale registration cleanup and added the `moveNestedRepositoryWorktree` (move and repair) and `trackNestedWorktreeUpstream` helpers. - Docs: `doc/recoverable-disk-cleanup.md` (new section about the conversion) and `doc/DEVELOPING.md` (settings). ## Verification - `cd server && pnpm exec vitest run src/__tests__/nested-clone-migration.test.ts`: 19 passed. It uses embedded Postgres and real git repositories, and covers: - Conversion with an unpushed commit, a second branch with unpushed commits, a lightweight tag and an annotated tag, staged and unstaged edits, a deleted file, an untracked file with mode 0600, an ignored file, `node_modules`, `.env` and the settings file. The result is a worktree of the shared clone (`--git-common-dir`), with the same HEAD, status, staged content and reflog, the owned branch tracking `origin/main`, and the history under the task's prefix. No other branch in the shared clone changes. The old clone is gone and reclaimed bytes are reported. - Skips with nothing changed: stash, live run, foreign origin, unknown checkout, no shared clone, local excludes, and a change between capture and verification (hook). - Two tasks convert concurrently against one shared clone. The test holds the shared-clone lock and shows that neither conversion advances. Then they run one at a time (peak 1), and each keeps its own branches. - Crash recovery at `afterAside`, `afterMove` and `afterFinalize` (roll forward), and before the swap (roll back, then convert). A dry run reports the pending record and changes nothing. - Expiration and restore of a converted checkout work afterwards. Unpushed branches in a converted checkout block expiration (`unpushed_managed_checkout_branches`). - Reaper: disabled by default; dry run changes nothing and registers no deadline; a live run registers a retry deadline that survives a second sweep; enabled conversion leaves no deadline. - Commits that only the clone's `origin` remote-tracking refs hold are kept as `paperclip/<id>/remotes/origin/<branch>`. - A pending conversion is finished after the workspace is archived, and forgotten (keeping unpushed branches) when the worktree is gone. - A filter planted in the shared clone right before the worktree add is refused (`unsupported_base_git_config`) and never runs. - Only checkouts named after configured project repositories are considered; at most 8 per sweep, pending first, rotating (unit test). - Related suites (run before review fixes; the nested, re-home and execution workspace service suites were rerun after them): `pnpm exec vitest run` on execution-workspaces-routes, execution-workspaces-service, git-reproducible-managed-checkouts, git-restore-point (all 5 files), git-workspace-contents, git-workspace-expiration, git-workspace-expiration-eligibility, heartbeat-git-restore-point-resume, heartbeat-project-repositories, isolated-repository-rehome, nested-clone-migration: 15 files, 393 tests passed. - `cd server && pnpm run typecheck` (`tsc --noEmit`): passes. - Mutation checks. Each mutation makes the targeted test fail, and I reverted each one: - Remove both eligibility checks: the live run test fails. - Remove the snapshot comparison: the capture/verify change test fails. - Disable roll forward after the swap: the recovery tests fail. - Drop the `paperclip/<id>/` prefix from transferred branches: the conversion and concurrency tests fail. - Remove the shared-clone lock: the concurrency test fails. - Drop remote-tracking refs from the plan, the deadline restore during backoff, archived recovery, or the config check before the worktree add: each targeted test fails. - Not run: the full server suite and a run on a live instance. ## Risks - The setting is off by default. Enable a dry run first and read the `execution_workspace.nested_clone_migration` logs. - A clone that a run writes to between verification and the swap rename can lose those writes. This window is the same as in #17369. Locks, the eligibility check and the git lock files make it small. - A crash in the short time between the rename aside and `git worktree move` can collide with a run that recreates `<name>`. In that case the conversion stops with `nested_migration_recovery_conflict` and keeps both copies. Expiration keeps such a workspace because of the `.clone-` names. - Stashes, annotated tag messages (the tagged commit is kept as a branch), custom hooks, custom local config and per-branch reflog-only history are not converted. Clones with them are skipped with a named reason. Only unpushed branches and tags get a name in the shared clone. A pushed local branch name is not kept, but its commits stay on the remote. - The conversion fetches the shared clone first. A failed fetch is ignored, and then the restore point can be larger. - Pushing from a converted checkout needs an explicit destination, as for all #17382 nested worktrees. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file editing, test execution). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-23 19:52:07 -07:00
Devin FoleyandPaperclip	0c3b5ce273	perf: filter sandbox provider lookups in Postgres (#17395 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Sandbox execution selects a provider from installed plugin manifests. > - Driver-key lookup reads every plugin row before it finds a matching declaration. > - Repeated lookups transfer manifests for unrelated plugins. > - The registry owns this database read and can filter candidates before returning rows. > - This pull request adds that filter and keeps the existing provider selection checks. > - The returned data now grows with matching providers instead of the full catalog. ## Linked Issues or Issue Description Problem or motivation `resolvePluginSandboxProviderDriverByKey` calls the unfiltered registry catalog on each lookup. The caller only needs plugins with a sandbox-provider declaration for one driver key. Unrelated plugin manifests still cross the database connection and are decoded in the server. Proposed solution Add an optional sandbox-provider driver-key filter to `pluginRegistryService().list`. Match the key and kind on the same JSON declaration in Postgres. Pass the key from the existing resolver. Keep full matching rows, install order, status checks and worker checks. Alternatives considered A catalog cache would need an invalidation contract for plugin updates and independent writers. This change keeps fresh database reads. Returning only one SQL row could skip a later eligible provider when an earlier worker is unavailable. The filter therefore keeps all matching candidates. Roadmap alignment This is a small performance fix to existing plugin execution. It adds no product feature or provider. Searches for sandbox/driver lookup and plugin catalog/filter work found no duplicate PR or issue. ## What Changed - Add an optional JSONB containment filter to the existing registry list read. - Use it in sandbox-provider lookup by driver key. The unfiltered catalog call keeps its existing behavior. - Add real-Postgres regression coverage and a short developer note. ## Verification - Four focused provider-selection/recovery/seam suites passed: 27 tests. - `pnpm build`: passed. - `pnpm -r typecheck`: passed. - The new Postgres tests seed large unrelated manifests and verify the actual resolver SQL filters rows in the database. They cover key/kind matching within one declaration, unfiltered reads, install order, disabled and unavailable workers, live status/declaration changes, unknown keys and bound unusual input. - The filter keeps the existing SQL call count. It does not add a network call, cache, timer, or background worker. - `git diff --check`: passed. Reviewed the staged diff for secrets and private account data before push. - Full PR CI passed on `6f97c984a931416b6347e9885d840557c54d8aab`: 54 successful checks and two expected skips. [Workflow evidence](https://github.com/paperclipai/paperclip/actions/runs/40041294925). - Apex review: 5/5 on that exact head, completed cleanly, with no comments or unresolved threads. Merge state is clean. - The prior local full run on parent work is documented in #17384. It did not pass because of test setup, host Git-default assumptions and transient failures. Those results were preserved and triaged against unchanged code. This change uses focused local checks and full current-head CI; no new local full-suite pass is claimed. - No hosted user journey, live provider throughput, production deployment or billed savings is claimed. ## Risks - JSONB containment checks the stored manifest before returning rows. It still scans candidate metadata in the database; no index or SQL-call reduction is claimed. - Both key and kind must match the same declaration. The regression fixture includes a plugin with those values on different declarations. - Selection still uses the existing install-order and live readiness/worker checks. Matching disabled records remain visible to callers that do not require a running worker. - No schema, API response, provider protocol, file-copy behavior or scheduling changes. ## Model Used OpenAI Codex, GPT-6 family. The exact deployment model ID and context window are not exposed in this session. Used reasoning, repository tools and code execution. ## 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>	2026-10-23 18:31:36 -07:00
Devin FoleyandPaperclip	8549ecaf9a	Re-home isolated repository workspaces onto the shared project clone (#17369 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Each isolated task workspace is a Git worktree on the server disk, and the terminal workspace reaper and git cache expiration keep that disk usage bounded > - For some days, workspace preparation gave each isolated `git_worktree` workspace its own full clone under `isolated-repository-sources/`, with the worktree inside it. #16963 removed that creation path, but the existing clones stay, and restoring an expired workspace still recreates its private clone > - On one instance, 30 such clones use about 23 GB: 12.1 GB of `.git` data, 5.2 GB of unused default-branch checkouts and 5.75 GB of real worktrees. 28 of them back open workspaces, and the disk is nearly full > - This pull request moves each such open workspace onto the project's shared managed clone with its exact state, deletes the private clone, and makes restore use the shared clone > - The benefit is that disk use drops to one shared clone per project repository, with no lost work and no change for workspaces that cannot move safely ## Linked Issues or Issue Description Refs #16963. Bug report described in-PR (bug report template). What happened? On one instance, 30 per-issue clones under `isolated-repository-sources/<companyId>/<issueId>/checkout` use about 23 GB. 28 of them back open workspaces. No process moves these workspaces to the shared project clone that new workspaces use, and git cache expiration does not remove a clone while its workspace is open. Reopening an expired workspace whose recipe has `sourceKind: "isolated_remote"` clones the full repository again. Separately, a restore point with a non-default file mode cannot be restored: the reference read back from jsonb has reordered `modes` keys, so `loadGitRestorePoint` fails with `restore_point_manifest_mismatch`. Expected behavior An open workspace with a private clone moves to the shared project clone with the same branch, HEAD, index, worktree, untracked and ignored files, and file modes. The private clone is then deleted. Reopening an expired workspace uses the shared clone when one exists. A restore point with non-default file modes restores. Steps to reproduce 1. Create an isolated `git_worktree` workspace with `materializeIsolatedRemoteWorkspaceSource` and record `isolatedRemoteSource` metadata, as preparation did before #16963. 2. Keep its issue open. The clone stays, because no sweep moves or removes it. 3. Expire the workspace with a restore point that has a file with mode `0600`, then reopen it. The private clone is created again, and the restore fails with `restore_point_manifest_mismatch`. Paperclip version or commit: `master` at `ec2e0d6407`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). ## What Changed - New `server/src/services/isolated-repository-rehome.ts` with `rehomeIsolatedRepositoryWorkspace`. It holds the isolated source lock, the `execution_workspace_lifecycle:<id>` advisory lock and expiration-style Git lock files (`index.lock`, `HEAD.lock` and the branch ref lock in the clone). - Eligibility uses the safety checks of git cache expiration that matter while a workspace stays open: no live or unfinished relevant runs, no unsettled native finalizations, no unreleased environment leases, no running runtime services, no pending reopen, and no other workspace on the same path. It does not require a closed or idle issue tree. The check runs again inside the update transaction. - The target base is the project's existing shared managed clone for the same `repoUrl` (the paths `ensureManagedProjectWorkspace` uses, verified with the same origin and storage checks as restoration). - The move captures a restore point of the old worktree. The upstream boundary is commits that both repositories have, so the bundle is small. It imports the bundle into the shared clone, creates `refs/heads/<branch>` or fast-forwards it from an ancestor, and adds the worktree at `<base>/.paperclip/worktrees/<branch>`. Then it applies the restore point. It copies the `HEAD` reflog and `ORIG_HEAD`, copies the branch's upstream config when it creates the branch, and moves regenerable directories, untracked `.env`/`.env.` files, `.claude/settings.local.json` and nested `.paperclip-repositories/` checkouts by rename. Standalone nested clones move as is. Nested checkouts that are worktrees of their own shared clone (#17382) move too, followed by `git worktree repair` in that clone so the registration follows the new path, and their `paperclip/<hash>/` branch is renamed to the new path's prefix so ownership checks still pass. Entries inside a moved nested checkout (for example its `node_modules`) move with it. Rollback and interrupted-move recovery repair them again after moving them back, and verification checks that each one still resolves to the same shared clone. - Verification: the restore point snapshot (HEAD, index, worktree, ignored files, modes) of the new worktree must equal the old one before and after the move. The reflog and `ORIG_HEAD` must match, and every moved item must exist. Only then does one transaction set `cwd`/`providerRef`, drop `isolatedRemoteSource` and `gitCacheExpiration`, rewrite a saved active restoration recipe to `managed_project`, and record `isolatedRepositoryRehome: { at, from, to, cleanedAt }`. A failure before that removes the new worktree, moves items back, restores the branch, and leaves the old worktree untouched. - Safety of the checkout in the shared clone: the move skips with `unsupported_base_git_config` when the shared clone's local config sets filter drivers, includes, attribute files, worktree config or command settings, or when it has `info/attributes`. It checks before planning and again right before `git worktree add`. - Crash safety before the update: the move records `isolatedRepositoryRehomePending` (base, target, branch, head, previous branch tip, planned moves) before the first change to the shared clone. The next attempt undoes an interrupted move under the same locks: it moves items back, removes the new worktree only when it is proven to be this move's (a linked worktree of the shared clone on the issue branch that no workspace row references), and restores the branch. A live failure removes the target only after this attempt created it. When an item exists in both places, rollback stops with `rehome_rollback_conflict` and keeps the target and the record, so no copy is lost. - Cleanup after the update: remove the old worktree (rename to trash, then delete, then `worktree prune`). Delete the clone (rename to trash, then delete) only when no other workspace, project workspace or running service uses it, it has no other worktree, its checkout has no changes or non-regenerable files, its refs are only branches, tags and remote-tracking refs, and every local commit is on a remote-tracking ref or present in the shared clone. Cleanup reads at most 5,000 refs, reflog entries and unique commits (`clone_history_budget`). `cleanedAt` records completion. A crash after the update leaves a pending record that the next pass finishes, also after the workspace is archived: the reaper scan includes archived rows with unfinished re-home cleanup when the feature is on. - Reaper integration in `sweepTerminalWorkspaces`: behind `PAPERCLIP_ISOLATED_SOURCE_REHOME_ENABLED` (default `false`) and `PAPERCLIP_ISOLATED_SOURCE_REHOME_DRY_RUN`, only when git cache expiration is enabled. It logs `event: "execution_workspace.isolated_source_rehome"` with outcome, reason, candidate bytes and reclaimed bytes. A skipped workspace gets a retry deadline one hour later in the reaper's existing deadline set. No new timer. - Restore: `reopenClosedIsolatedExecutionWorkspaceForIssue` calls `rehomeExpiredIsolatedRestoration` first. For an expired workspace with an `isolated_remote` recipe, it uses the shared clone when one exists and the branch there is absent or at the saved commit. It keeps the old behavior for recipes with worktree-backed nested checkouts on branches, because those branch names are bound to the old path. It also requires that the shared clone has every base commit (prerequisite) of the saved restore point bundle. It rewrites the row and recipe to the shared clone and the standard worktree path, then the existing restore runs (`ensureGitRestorePointCommit`, `ensureSavedGitCommit`, apply). Without a shared clone, the old behavior stays. - Fix: restore point `modes` comparison in `git-restore-point-storage.ts` compares by path and mode, so jsonb key order does not matter. - Small exports: `allocatedBytes`, `expirationScope`, `managedSourcePaths`, `verifiedGitCacheSource`. - Docs: new "Isolated repository sources" section in `doc/recoverable-disk-cleanup.md`, new settings in `doc/DEVELOPING.md`. Deviations from the requested design: - The sweep does not create a missing shared clone. When none exists, it skips with `no_shared_base`, because a new network clone in a cleanup path can use more disk. Restore follows the same rule and keeps the old behavior. - History moves through the restore point bundle, not a separate fetch from the clone. The bundle contains HEAD and every reflog/`ORIG_HEAD` commit that the shared clone does not have. The move then checks that all of them are present. - The standard location is `<base>/.paperclip/worktrees/<branch>`. A worktree outside the clone's standard location is skipped (`nonstandard_worktree_location`). - Lock files use a token derived from the workspace id, so a crashed attempt's locks are recovered without a database marker. - A clone that another open workspace still uses is kept and marked `cloneRetained: "base_has_consumers"`. That workspace's own move removes it later. Skip reasons: `live_or_unresolved_consumer`, `unsupported_base_git_config`, `rehome_rollback_conflict`, `nested_branch_conflict`, `invalid_rehome_record`, `interrupted_rehome_pending` (dry run only), `lifecycle_busy`, `source_busy`, `workspace_changed`, `no_shared_base`, `shared_base_repo_mismatch`, `missing_worktree`, `nonstandard_worktree_location`, `source_identity_changed`, `branch_identity_changed`, `unproven_worktree_admin`, `unsupported_worktree_git_state`, `unique_worktree_refs`, `unknown_worktree_git_logs`, `unsupported_local_git_state`, `unique_git_refs`, `unsupported_index_flags`, `unsupported_branch_name`, `invalid_restoration_recipe`, `unsupported_restoration_recipe`, `target_worktree_exists`, `base_branch_checked_out`, `base_branch_diverged`, `untransferable_ignored_files`, `untransferable_managed_checkouts`, `worktree_git_busy`, `head_changed`, `history_not_transferred`, `transfer_conflict`, `snapshot_mismatch`, `history_mismatch`, `transfer_incomplete`, and restore point reasons such as `untracked_nested_repository`, `submodules_unsupported`, `filtered_paths`, `restore_point_too_large`. Clone kept reasons: `base_has_consumers`, `base_has_live_services`, `base_has_worktrees`, `clone_checkout_has_files`, `unsupported_clone_refs`, `unique_clone_history`, `clone_history_budget`. ## Verification - `pnpm exec vitest run src/__tests__/isolated-repository-rehome.test.ts` in `server/`: 18 passed. It uses real Git repositories and embedded Postgres. It covers: - a move with an unpushed commit, staged and unstaged edits, a deletion, an untracked file with mode `0600`, an ignored file, `node_modules`, `.env`, `.claude/settings.local.json` and a nested `.paperclip-repositories` checkout. Snapshots, branch, HEAD, `git status` and reflog match, the row points to the new path without `isolatedRemoteSource`, and the old worktree and clone are gone; - skips with nothing changed on disk or in the database: live run, branch in the shared clone at an unrelated commit, no shared clone, an untracked nested repository, and a concurrent change between capture and verify (hook). The new worktree is removed and the old one keeps its moved items; - the clone is kept while another workspace references it; - a worktree-backed nested checkout moves with the task worktree, stays registered in its shared clone at the new path (not prunable), and keeps its changes, with its branch renamed to the new path's prefix. On rollback it returns to the old path with its registration repaired and its branch name restored. A standalone nested checkout moves together with its own ignored `node_modules`; - a file recreated in the old worktree before verification stops the rollback and keeps both copies, then the move completes once the conflict is gone; - a hostile `filter..smudge` in the shared clone's config makes the move skip without running it; - a clone with more than 5,000 refs is kept, and is deleted once the refs are gone; - a move interrupted before the database update is reported (not undone) by a dry run, then undone and completed on the next attempt; - a target that another party creates right before `git worktree add` is never deleted; - a crash after the database update; after the row is archived, a later reaper sweep removes the old worktree and clone; - restore keeps the private-clone fallback when the shared clone lacks the restore point's base commits; - disabled by default (both flags needed), dry run changes nothing, and the retry deadline is registered; - reopening an expired `isolated_remote` workspace rebuilds it in the shared clone with the restore point applied and no clone created. - After the round 4 fixes, the related suites (`git-workspace-expiration`, `git-restore-point-expiration`, `execution-workspace-reopen`, `execution-workspaces-service`, `heartbeat-git-restore-point-resume`, `heartbeat-project-repositories`, `isolated-remote-workspace-source`) with the new suite: 326 passed. - After rebasing on #17382, the related suites (adding `heartbeat-project-repositories`) with the new suite: 374 passed. - After the first review fixes, the related suites (`git-workspace-expiration`, `git-restore-point`, `git-restore-point-expiration`, `execution-workspace-reopen`, `execution-workspaces-service`, `execution-workspace-compaction`, `heartbeat-git-restore-point-resume`, `isolated-remote-workspace-source`) with the new suite: 301 passed. - Related suites in `server/` (first commit): `pnpm exec vitest run` on `git-workspace-expiration`, `git-workspace-expiration-eligibility`, `git-restore-point`, `git-restore-point-expiration`, `git-restore-point-expiration-config`, `git-restore-point-ledger`, `git-restore-point-ledger-config`, `execution-workspace-reopen`, `execution-workspaces-service`, `execution-workspace-compaction`, `heartbeat-git-restore-point-resume`, `isolated-remote-workspace-source`, `isolated-remote-workspace-source-lock`, `git-workspace-base-storage`, `git-reproducible-managed-checkouts`, `git-expiration-auth-fallback` and `workspace-runtime`: 550 passed, 2 failed. The 2 failures are in `workspace-runtime.test.ts` (base ref resolution) and also fail on unmodified `master` on the same machine. - `pnpm run typecheck` in `server/` passes (after `pnpm -r --filter "./packages/*" build`). - Mutation checks. Each reverted guard fails one test in the new suite: - eligibility always true: "keeps a workspace with a live run" fails; - snapshot verification removed: "removes the new worktree and keeps the old one when the workspace changes during the move" fails; - clone reference check removed: "keeps the clone while another workspace still references it" fails; - restore re-home removed from reopen: "restores an expired isolated workspace into the shared project clone" fails; - old `JSON.stringify` modes comparison: the same restore test fails; - interrupted-move recovery removed: the interrupted-move test fails; - target existence check before `git worktree add` replaced by assumed ownership: the foreign-target test fails; - bundle prerequisite check removed: the stale shared clone restore test fails; - archived-row cleanup scan removed: the crash test fails; - dry run check before interrupted-move recovery removed: the interrupted-move test fails; - `git worktree repair` after the forward move removed: both nested worktree tests fail. The repair after moving back removed: the rollback test fails; - nested branch rename forward or back removed: the matching nested test fails; - rollback conflict check removed: the reappearing-file test fails; - covered-entry filter removed: the full re-home test fails; - shared clone config check removed: the hostile filter test fails; - ref budget removed: the many-ref test fails. - Not run: the full server suite, and the move on a live instance. ## Risks - Workspace paths change for re-homed workspaces. Agents that resume an old session can remember the old path. The run's working directory comes from the updated row, but text in a resumed conversation can still name the old path. - The feature is off by default. It runs only with `PAPERCLIP_ISOLATED_SOURCE_REHOME_ENABLED=true` and git cache expiration enabled. Dry run is available. The restore change is not behind the flag: reopening an expired private-clone workspace now uses the shared clone when one exists. - A run can start between the last eligibility check and the database update. The update transaction checks eligibility again, and the old worktree is deleted only after another check. This is the same window that git cache expiration accepts. - Imported restore point objects stay in the shared clone as unreachable objects after a failed attempt until Git garbage collection removes them. Base expiration keeps a base with unreachable objects, so this only delays base expiration. - A workspace that cannot move (for example `no_shared_base`) is retried each hour while the feature is on. Each retry runs a few Git commands for that workspace. - No migration. No schema change. ## Model Used Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file editing, Git, test runs). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-23 18:25:26 -07:00
Nicky Leach	100477e887	Avoid live workspace inspection in task context reads (#17396 )	2026-10-23 17:05:06 -07:00
Devin FoleyandPaperclip	ec2e0d6407	Share one clone across nested project repository checkouts (#17382 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A project can attach extra repositories, and every task worktree gets a managed checkout of each one under `.paperclip-repositories/<name>` > - Each of these nested checkouts is a full clone. The clone uses `--dissociate`, so no objects are shared between tasks > - On one instance, 44 task worktrees held nested checkouts of the same repository: 24 GB of 27 GB of worktrees. Each new task added about 0.5 GB, and the disk filled twice in one day > - Main task worktrees already avoid this, because they are git worktrees of one managed project clone > - This pull request makes nested checkouts git worktrees of one shared clone per project and repository, and adapts expiration, restore points, restore and cleanup to them without weaker safety checks > - The benefit is that repository objects are stored once, and a new task adds only its working files ## Linked Issues or Issue Description No public issue exists. This is the in-PR bug report. What happened? Every task in a project with extra repositories got a full, independent clone of each extra repository under `.paperclip-repositories/`. On one instance this used 24 GB of 27 GB of task worktrees (16 GB of it `.git` data) and filled the disk twice in one day. Expected behavior Nested checkouts of the same repository share one object store, like main task worktrees share the managed project clone. Disk use per new task is only its working files. Steps to reproduce 1. Create a project with a primary repository and a second repository that has a repository URL and no local folder. 2. Run several tasks in isolated git worktrees in that project. 3. Look at `<task worktree>/.paperclip-repositories/<name>/.git`: each one is a full directory with its own copy of every object. Paperclip version or commit: `master` at `ff835a3fc6`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). Related: #15662 (SSH restores skip nested worktrees) touches a different path; this PR does not change adapter sync. ## What Changed - New `server/src/services/nested-repository-worktrees.ts`. It finds the shared clone (the managed project checkout for the repository URL, from `ensureManagedProjectWorkspace`), adds nested worktrees, restores them, removes their registrations, and serializes all of these operations and fetches per shared clone with an in-process lock. - `prepareProjectRepositoryWorkspaces` takes a `sharedBase` (company and project). For a repository without a configured local folder, it fetches the shared clone and adds a worktree at the same `.paperclip-repositories/<name>-<key>` path. Each worktree gets its own branch `paperclip/<id>/<branch>` that tracks `origin/<branch>` (`<id>` derives from the worktree path), or a detached HEAD for a tag or commit ref. An existing worktree must belong to the project's shared clone. Configured local-folder copies and existing standalone clones are unchanged. Moving a worktree to `detached-repositories` repairs its registration. Heartbeat preparation and fresh-start reopening pass `sharedBase`. - `assertReproducibleManagedCheckout` and `provenManagedCheckoutHistory` accept worktree-backed checkouts. They verify the worktree link, its admin directory, the shared clone identity and origin, and that HEAD is detached or on a branch under the worktree's own prefix. History checks scope to HEAD, the per-worktree HEAD reflog, ORIG_HEAD and the owned branches with their reflogs. Other tasks' branches are not inspected. Stashes, unsupported refs and custom config in the shared clone still block. The upstream proof reads objects from the common git directory. - Restoration contents record `worktree: { base, admin }` for a worktree-backed checkout. Validation checks its shape and the owned branch name, and every use checks the base against the project's expected clone paths. - Expiration locks for a worktree-backed checkout sit in the shared clone (`.git/worktrees/<admin>/index.lock`, `HEAD.lock`, and the owned branch ref lock). `gitCacheExpirationLockLocations` is now async. - `finishGitCacheTrash` removes the expired worktree's registration and deletes its owned branch only at the recorded commit. - `restoreGitWorkspaceContents` recreates a worktree-backed checkout from the shared clone, and clones the shared clone again if it is gone. It imports the restore point into the shared clone, adds the worktree on the saved branch and commit, writes reflog-only commits back into the new HEAD reflog, and applies the restore point. - `cleanupExecutionWorkspaceArtifacts` (terminal reaper archival, close and delete) collects the task's nested worktrees first. After the task directory is gone, it removes their registrations and deletes owned branches only when every commit is on a remote-tracking ref. An unpushed branch stays in the shared clone. - Review follow-ups. Owned branches always track origin, including names with dots, and the config check accepts their tracking keys. A ref held by a retained detached checkout gets `paperclip/<id>/r<n>/<branch>`. Restore derives the upstream from the saved source ref. Each new worktree fetches with `--prune`, refreshes `origin/HEAD` when no ref is configured, and strips `refs/heads/` from branch refs. Git commands on the shared clone run with hooks disabled. The worktree `gitdir` pointer is read through a bounded, non-following, non-blocking handle, and more than 64 owned branches stop the proof before reflog reads. - Docs: new "Nested project repository worktrees" section in `doc/recoverable-disk-cleanup.md`, and updates in `doc/DEVELOPING.md`. ## Verification - `pnpm -r --filter "./packages/*" build`, then `pnpm run typecheck` in `server/`: passes. - `pnpm exec vitest run` in `server/` for `git-workspace-expiration`, `git-reproducible-managed-checkouts`, `git-workspace-contents`, `git-restore-point`, `heartbeat-project-repositories`, `execution-workspaces-service`, `execution-workspaces-routes`, `execution-workspace-compaction`, `workspace-compaction`, `heartbeat-git-restore-point-resume`, `managed-repository-checkout`, `task-workspace-repositories`, `native-workspace-sync`, `heartbeat-managed-clone-credentials`, `services/heartbeat/workspace-preparation`, `project-repositories-persistence`, `git-workspace-base-storage`, `agent-directory-probe`, `workspace-runtime`, `workspace-preparation-history` and `native-completion-feedback`: 866 passed, 2 failed. The 2 failures are in `workspace-runtime.test.ts` (`rejects explicit main on a master-only remote...` and `does not diagnose a missing remote branch...`). They fail the same way on unmodified `master` on this machine. - New tests (embedded Postgres, real git repositories) in `git-workspace-expiration.test.ts`, section "nested checkouts as worktrees of a shared base": - Two tasks get worktrees of one shared clone. `--git-common-dir` points to it, each task has a distinct `paperclip/<id>/main` branch, upstream is `origin/main` and the remote is the repository URL. - Concurrent preparation of three tasks succeeds, and preparation waits while the shared clone lock is held. - A legacy standalone clone is still adopted, and no shared clone is created for it. - Expiring a clean nested worktree removes only its registration and branch. The sibling worktree and branch stay. Reopening recreates the worktree from the shared clone on the same branch and commit, with its local settings. - Reopening clones a deleted shared clone again. - Unpushed commits and uncommitted files block plain expiration, are saved in a restore point and are restored exactly. - Reflog-only history is saved and written back into the restored HEAD reflog, and it survives `gc --prune=now` of the shared clone. - Stashes, a checked-out branch outside the worktree's prefix, and unpushed owned branches or owned reflog entries outside HEAD history block expiration. - Another task's unpushed branch does not block, and it stays after expiration. - A worktree of a foreign clone at the nested path is rejected by preparation and by the prover. - Expiration locks in the shared clone are recovered after a process exit. - Deleting a task removes only its nested registrations, keeps its unpushed branch and deletes the sibling's pushed branch when the sibling is deleted. - Follow-up tests: dotted branch tracking, a ref switched away and back with a retained checkout, a changed remote default branch, a renumbered branch restored next to a same-named remote branch, a fully qualified branch ref after the remote advances, a branch deleted upstream, planted `post-checkout` and `reference-transaction` hooks, more than 64 owned branches, and a FIFO, oversized or symlinked `gitdir` pointer. Each fix was mutation-checked. - `heartbeat-project-repositories.test.ts`: a repository-URL-only sibling is now a worktree of the shared clone on an owned branch, and its detached copy is still a valid checkout after its repository leaves the project. In `workspace-preparation.test.ts`, the publication guard now runs before any worktree exists. - Mutation checks. I reverted one guard at a time and confirmed that a test fails: the owned-HEAD check, the owned-branch check in restore point mode, the owned-reflog check, the shared-clone identity check, the pushed-only branch deletion on cleanup, the cleanup release hook, the registration removal on expiration, the reflog-only history write-back on restore, and the shared clone lock. The owned-branch-tip check alone is also covered by the owned-reflog check, so removing only one of the two keeps the tests green. - Not run: the full server test suite, the UI and e2e suites, and a live instance migration. ## Risks - Behavior change for agents: a nested checkout of a URL-only repository is now on `paperclip/<id>/<branch>`, not `<branch>`. `git pull` and `git status` work as before. A plain `git push` now fails because the branch names differ. Agents must push with an explicit destination, for example `git push origin HEAD:<branch>`. Branches in the shared clone are visible to all tasks of the project, like main task worktree branches. - Agent-created branches outside the worktree's prefix, stashes, and local config live in the shared clone. Stashes and custom config block expiration of every worktree of that clone (fail-closed). Other branches stay in the shared clone after a task is deleted. - The shared clone is the managed project checkout for that repository URL. Fetches into it update its remote-tracking refs. A concurrent restore point capture of a sibling can then roll back and retry on the next sweep. - The base lock is per process. Across processes, git's own ref and index locks apply. - No migration in this PR. Existing standalone nested clones keep their disk use until their tasks are removed or expired. A safe migration helper is a follow-up. Task repositories (`task-repo-*`) and configured local-folder copies stay standalone clones. - Restoration recipes now can carry `contents.checkouts[].worktree`. An older server rejects such a recipe as invalid (fail-closed) and does not restore without it. ## Model Used Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file editing, test execution). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-23 16:05:13 -07:00
Devin FoleyandPaperclip	4660b22f6b	perf: narrow run bindings during event ingestion (#17378 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent runs append native events and retry-exhaustion receipts. > - These writes lock the run row and verify its company and agent bindings. > - The binding check fetched the full run, including prompts, configuration, and output. > - This pull request reads only the two fields that the check uses. > - The benefit is less database transfer while the same row lock protects sequence allocation and replay checks. ## Linked Issues or Issue Description Related: #17355 and #17348 reduce other run-read payloads. GitHub searches for event-read and narrow-run PRs found no duplicate of this event-ingestion change. What existing behavior does this improve? The run binding read during native event and retry-exhaustion ingestion. Current behavior The transaction uses a full-row `SELECT ... FOR UPDATE` to check only `companyId` and `agentId`. Large run context, runner configuration, and output cross the database connection for each such check. Proposed behavior Select only the company and agent IDs. Keep the same run ID predicate, row lock, transaction, sequence allocator, replay cursor, and binding checks. Reason and benefit The check does not use the other fields. Narrowing the query removes that repeated transfer without a cache or an authorization change. Breaking changes None. No API response, schema, event, or scheduling changes. ## What Changed - Narrow the existing run-row read inside `appendHeartbeatRunEvent`. The event service continues to own its transaction and binding validation. - Exercise native and retry-exhaustion writes and replays with large stored payloads. Record the executed SQL to prove the lock reads only the two binding fields. - Extend missing-run and company/agent mismatch coverage to both transaction paths. Keep the existing concurrent-writer and rollback tests. - Document the read boundary. ## Verification - Focused PostgreSQL event append and sequencing suites: 9 tests passed. They include concurrent writers, replay conflicts, rollback, cursor checks, large payloads, and company/agent/missing-run denials. - The first new retry-exhaustion fixture failed its duplicate assertion because it omitted the exhaustion fields from the event payload. The existing producer contract stores those fields in the payload. The fixture now does the same; the rerun passed. No production retry or replay logic changed. - `pnpm build`: passed. - `pnpm -r typecheck`: passed. - Greptile Apex: 5/5 on `76a6d3ee813ae47919b1ec8e8b88e01e58d5655d`, clean check and no review threads. The [full PR workflow](https://github.com/paperclipai/paperclip/actions/runs/40028758665) passed on that exact head: 54 checks passed and two conditional checks were skipped. The branch is conflict-free. - The full local all-in-one suite is not repeated for this follow-up. Full exact-head CI will supply the broader suite coverage. - No hosted deployment or bill reduction is claimed for this follow-up. ## Risks - Low scope: only the selected columns change. The `FOR UPDATE` lock, transaction boundaries, sequence reservation, duplicate checks, and failure handling remain in place. - Native replay and legacy event writers must still serialize on the same row. Existing real PostgreSQL concurrency tests cover that boundary. - No migration, provider change, new timer, or operator configuration is required. ## Model Used OpenAI Codex (GPT-6 family), with code execution and repository tools. The runtime does not expose the exact model ID or context window. ## 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 #` 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 (focused suites above) - [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>	2026-10-23 15:09:29 -07:00
Devin FoleyandPaperclip	dfe7df0015	fix(native): expire settled native workspace sync folders (#17358 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Native runs sync their workspace with a remote sandbox through a per-run folder under `<instance>/native-workspace-sync/<run>/` > - The folder holds a descriptor, a manifest, and workspace and git seed archives, and a seed can be more than a gigabyte > - Only a few finalization commit paths delete the folder, so many runs leave it on disk forever > - Instance disks fill up with folders that no code will read again > - This pull request adds a bounded, deadline-driven retention worker that removes a folder only when no reader can still need it > - The benefit is that instance disks stop growing with stale sync folders, and recovery and export paths keep their files ## Linked Issues or Issue Description What happened? `cleanupNativeWorkspaceSync(runId)` is the only code that deletes `native-workspace-sync/<run>/`. It runs only when finalization commits through specific paths. Runs that end in `terminal_failure`, retained recovery, reconstruction, superseded runs, commits through other paths, and server crashes leave the folder forever. On one instance, 22 folders older than 7 days held 6.8 GB. Single seed archives were up to 1.4 GB. Expected behavior A run's sync folder is removed after a retention window, once the run and its finalization are settled and no recovery or export path can still read it. The shared `generations` seed cache stays. Steps to reproduce 1. Run a native agent with a remote sandbox and let the run end in `terminal_failure` (or crash the server during finalization). 2. Wait more than 7 days. 3. Look in `<instance>/native-workspace-sync/`. The run's folder and its seed archives are still there. Paperclip version or commit `master` at `837add0caa` Deployment mode Any deployment that runs native agents with remote sandboxes. Agent adapter(s) involved Native runtime with remote sandbox workspace sync (for example Codex on Daytona). ## What Changed - Added `server/src/services/native-runtime/native-workspace-sync-retention.ts`. It removes `native-workspace-sync/<name>/` when `<name>` is a UUID, the entry is a real directory, its newest file is older than the window, and one of these holds: - no `heartbeat_runs` row has that id (orphan); - the run has no valid `nativeWorkspaceSync` reference and is settled: terminal status, `finished_at` before the window, no live recorded process (see below), no live controller lease, no `nativeWorkspaceFinalizationOwner` receipt; - the run is settled as above, its `native_run_finalizations` row (if any) has no `lease_owner` and no `next_attempt_at` and is `committed` (any recovery state) or `terminal_failure` with no or `blocked` recovery state, no active/escalated export-cause or owner-unverified recovery action names it, no lease carries `nativeWorkspaceExportResume` or `pendingCleanupInFlight`, retained recovery cannot still use it (referenced lease destroyed, or no scheduled/running/awaiting_evidence system recovery and no queued/recovering workspace recovery), and historical recovery adoption (`adoptHistoricalWorkspaceRecoveries`) has no pending candidate for it. - Each folder is decided in one transaction that holds `pg_try_advisory_xact_lock` on the run's finalization ownership key. The rule is evaluated while the lock is held. A held lock skips the folder. The folder is renamed to `.expired-<uuid>` in that transaction and deleted after commit. The next sweep removes leftover `.expired-` folders. `generations`, non-UUID names, symlinks and files are never touched. Each tick tries at most 50 leftovers, then checks at most 200 folders and removes at most 50. Leftovers and folders each continue from their own cursor, so undeletable leftovers do not block run folders. A leftover that cannot be deleted schedules the 15-minute retry. Deadline discovery reads run state 200 IDs at a time and stops when asked to. It supports dry run and `shouldContinue`. - A recorded `process_pid` / `process_group_id` blocks removal only while it can still be the run's own process. This reuses the rule from `conversation-continuation.ts`: PIDs are ignored when every lease of the run is remote (they are sandbox PIDs), and a local PID or process group blocks only while it exists on this host and its start time matches `process_started_at`. An unreadable start time keeps the folder. A recycled PID does not. - Separate finding, not changed here: native runs do not clear `process_pid` when they finish. It is cleared only by the status arbiter's `release_run_resources` effect (cancellations and commits) and by the recovery paths. A failed run gets a `schedule_retry` effect instead, so its PID stays set. For remote targets the stored value is the sandbox PID. Other readers already treat these PIDs as liveness hints only, so this PR does not change that write path. - Exported `nativeWorkspaceFinalizationLockKey` from `native-workspace-finalization-ownership.ts` and used it in `withNativeWorkspaceFinalizationOwnership` and the retention worker, so both use the same key derivation. - Exported `nativeWorkspaceSyncStateRoot()` from `native-workspace-sync.ts`; `descriptorDirectory` now uses it. - Registered the worker on the shared delivery-work coordinator (`DELIVERY_QUEUES.nativeWorkspaceSyncRetention`) in `server/src/index.ts`, next to the git restore point worker. It follows `rules/sleep-aware-background-work.mdc`: no interval. It runs at startup and at real deadlines: the earliest settled run's finish (or an orphan's newest file) plus the window; a recheck one window later for folders it kept; and a 15-minute retry after a failure or a held lock. With no folders, `nextRunAt` is `null`. The run folder is now created through one helper in `native-workspace-sync.ts` that notifies process-local listeners; the worker wakes on that signal only while it has no deadline, because any scheduled deadline is never later than a new folder's own deadline. `index.ts` unsubscribes the listener on shutdown. It pauses passive maintenance during idle drain. - Added `PAPERCLIP_NATIVE_WORKSPACE_SYNC_RETENTION_ENABLED` (default on unless `false`), `PAPERCLIP_NATIVE_WORKSPACE_SYNC_RETENTION_DRY_RUN` (default off) and `PAPERCLIP_NATIVE_WORKSPACE_SYNC_RETENTION_DAYS` (default `7`, minimum `1`) in `server/src/config.ts`. Documented them in `doc/DEVELOPING.md` and added a "Native workspace sync folders" section to `doc/recoverable-disk-cleanup.md`. ## Verification - `pnpm exec vitest run src/__tests__/native-workspace-sync-retention.test.ts src/__tests__/native-workspace-sync-retention-config.test.ts` in `server/`: 62 tests pass. They cover: - deletes a settled committed run (also with a left-over `resuming_session` recovery state), a blocked `terminal_failure` with no recovery owner, an orphan, and an unreferenced settled run; - keeps runs whose local process or process group is still alive, or whose live process start time cannot be read; keeps a running run with a PID; deletes terminal runs whose recorded local process exited, whose PID was recycled, or whose PID came from a destroyed sandbox; - keeps recent files, recently finished runs, unsettled runs, a live controller lease, an owner receipt, `observed` and `retryable_failure` phases, a live `lease_owner`, a scheduled `next_attempt_at`, and each non-blocked recovery state on `terminal_failure`; - keeps runs with an open export-cause or owner-unverified recovery action, `nativeWorkspaceExportResume` or `pendingCleanupInFlight` lease metadata, retained recovery in flight on a lease that was not destroyed, or pending historical recovery adoption; deletes when the retained lease was destroyed; - never touches `generations`, non-UUID names, symlinks or files; dry run deletes nothing; leftover `.expired-` folders are removed; an advisory lock held by another transaction makes it skip; ticks are bounded and resume from a cursor; - `nextDeadlineAt` returns `null` with no folders, now with leftovers, the settled finish plus the window, the orphan mtime plus the window, and one window later for kept folders; the registered worker goes quiet with no folders, retries after a held lock or an undeletable leftover, and the real delivery-work coordinator wakes again when the real producer (`writeDescriptor`) creates a run folder; leftover removal is bounded and undeletable leftovers do not block run folders. - Mutation checks: I removed each guard one at a time (advisory lock, owner receipt, process pid, finished_at window, lease owner, next attempt, phase, recovery state, export recovery, owner-unverified, export resume, retained recovery, backfill pending, symlink/real-directory check, dry run, and both mtime checks together, plus the folder-creation wake, the process liveness rule (restoring the old `process_pid IS NULL` rule, the sandbox exemption, the process group check, the recycled-PID check, the unreadable start time), the leftover batch limit, the leftover cursor and the leftover retry delay). Each mutation made at least one test fail. I restored the code after each one. Removing only the first mtime check does not fail a test, because the second check inside the transaction still keeps the folder. - `pnpm exec vitest run` on related suites in `server/`: `native-workspace-sync.test.ts`, `native-workspace-sync-history.test.ts`, `native-workspace-finalizer.test.ts`, `native-workspace-finalizer-failure.test.ts`, `native-harness-backup-expiration.test.ts`, `git-restore-point-ledger.test.ts`, `delivery-work-coordinator.test.ts`, `chat-delivery-work.test.ts`. All pass. - `pnpm run typecheck` in `server/` passes. - Greptile review: earlier rounds; all findings fixed with tests; final score 5/5 with no open threads. - Not run: the full server test suite and an end-to-end run against a real instance. I did not measure disk savings on a live instance. ## Risks - Deleting a folder that a reader still needs would make that path fall back or fail. Same-run resume and export run under the finalization ownership lock or before the run settles, and the worker checks the rule while it holds the same lock. Retained workspace recovery already handles a missing folder (ENOENT) by snapshotting the sandbox. The rule keeps the folder for every in-flight or reopenable recovery state listed above. - A committed finalization row with a stale recovery state and no lease owner is treated as settled. Nothing reads the recovery state of committed rows. - The worker is on by default. Operators can set `PAPERCLIP_NATIVE_WORKSPACE_SYNC_RETENTION_DRY_RUN=true` first to see candidates in the log, or turn it off with `PAPERCLIP_NATIVE_WORKSPACE_SYNC_RETENTION_ENABLED=false`. - The first sweep on a large instance does more filesystem work. It is bounded to 200 folders checked and 50 removed per tick. - The folder-creation wake is process-local. A folder created by another server process sharing the same instance directory is picked up at the next deadline or restart. - A stale `process_pid` no longer blocks removal. If a run's local process is still alive with its recorded start time, the folder stays. Live work is also still guarded by the run status, controller lease, finalization lease and ownership lock checks. - No schema migration. > 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 - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file edits, test runs). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-23 14:05:55 -07:00
Devin FoleyandPaperclip	ef9e17304c	perf: narrow runtime progress database reads (#17355 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Active runs publish workspace and provider progress. > - Each update must check the current run status before it publishes. > - This check fetched the full run, including prompts and runner configuration. > - This pull request reads only the four fields that progress publication uses. > - The benefit is less database transfer while each update still checks durable state. ## Linked Issues or Issue Description Related: #17348 narrows authorization reads. This PR applies a separate projection to runtime progress. GitHub searches for runtime progress and run-status read PRs found no duplicate. What existing behavior does this improve? The database read before a runtime progress update. Current behavior Each update calls `getRun`. This reads large run context and runner configuration even though progress publication only uses the run ID, company ID, agent ID, and status. Proposed behavior Use a fresh four-column read for each update. Keep the existing active-status check, event fields, error propagation, and late-progress suppression. Reason and benefit Transfer progress can emit many updates for one run. A small status check avoids repeatedly transferring payloads that it does not use. Breaking changes None. No API response, schema, scheduling, or cancellation policy changes. ## What Changed - Add `getRunStatus` to the run-state owner. The full reader remains available to consumers that need execution data. - Wire the narrow reader into the lifecycle progress check. Remove the unused context field from that check's input contract. - Cover the exact selected fields, missing runs, database errors, large stored payloads, terminal transitions, and the public heartbeat service wiring. Document the read boundary. ## Verification - Run-state and lifecycle suites: 44 tests passed before the additional public-service regression. - Lifecycle, public-service wiring, and native cancellation suites: 36 tests passed. - `pnpm -r typecheck`: passed. - `pnpm build`: passed. - The [full PR workflow](https://github.com/paperclipai/paperclip/actions/runs/40013092548) passed on `95bf496f689049812646b5ccddcdf2cca21efad0`. All 54 reported checks passed; two conditional checks were skipped. This includes test shards, browser checks, Runner verification, production bundle boot, and clean npm installation. - `GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=init.defaultBranch GIT_CONFIG_VALUE_0=master pnpm test:run`: an additional local all-in-one run is still in progress; no full-local-pass claim. The process-scoped Git default matches existing master-only fixtures and does not change user configuration. - The initial description check failed because the dedup-search checkbox was missing. Searches are complete and the template checkbox is now included. The rerun passed on the same source commit. - Greptile Apex: 5/5 on `95bf496f689049812646b5ccddcdf2cca21efad0`, no findings or review threads. - No hosted deployment or bill reduction is claimed. CI and Apex are complete; this PR is merge-ready. ## Risks - Low scope: the query selects fewer columns and preserves the existing status read on every progress callback. It adds no worker, cache, timer, or idle query. - A run can still finish after the status read and before publication, as it could before this change. This PR does not change that concurrency boundary. - No migration or operator configuration is required. ## Model Used OpenAI Codex (GPT-6 family). The runtime does not expose the exact model ID or context window. ## 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 #` 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 (focused suites above; full suite is still running) - [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>	2026-10-23 12:50:36 -07:00
Devin FoleyandPaperclip	f406b32d08	perf: narrow run authorization reads (#17348 ) ## Thinking Path > - Paperclip lets people manage and observe AI agents at work. > - Live events and run history must enforce current task permissions. > - Some permission checks load the complete run record for each event or request. > - Run context, runner configuration, results, and output can make those records large. > - This pull request reads only the persisted fields each access check needs. > - The checks still read current permissions and fail closed. ## Linked Issues or Issue Description Related: #17251, #9155, and #16229. Those changes cover other run projections, recovery polls, and task history. This change covers live-event delivery, workspace-operation run checks, and event-list access. What happened? Live-event delivery loaded every run column for each subscribed viewer, although the permission helper used only the company, run scope, and task binding. Workspace-operation checks did the same. The run-event endpoint also loaded complete run records before returning separate event rows. Large contexts and runner configurations therefore increased database transfer for ordinary access checks. Expected behavior Read only the stored access binding. Keep company checks, permission freshness, deleted-task tombstones, and response bodies unchanged. Steps to reproduce 1. Create an issue-bound run with large context, runner configuration, and output fields. 2. Subscribe an authorized viewer to company live events and publish run updates. 3. Read the run events and a linked workspace operation. 4. Inspect the run SELECT projections. The previous queries load fields that the access checks do not use. Paperclip version or commit The defect is present on the current master base, `62c78e56e53`. Deployment mode Authenticated server with PostgreSQL. The defect is not adapter-specific. ## What Changed - Select only company, scope, and issue bindings for live-event and workspace-operation run authorization. - Add a four-field run-access read for event-list requests. Reuse those columns in the existing log-access projection. - Preserve per-delivery and per-request permission checks, company predicates, and event responses. - Add real PostgreSQL and WebSocket coverage with large run fixtures. Cover grant revocation, grant restoration, deleted tasks, missing and foreign-company runs, and failed reads. - Document the bounded access reads in the existing polling-load guide. ## Verification - Six focused suites pass: 40 tests. They cover the changed paths, run-state reads, run logs, disconnect retries, and native event replay. - The new WebSocket test uses the production delivery path and a real database. It verifies that the selected SQL omits large run fields while authorization changes take effect on the same open socket. - The event-route test preserves the returned event content and denies the next request after grant revocation. - Local recursive typecheck, full build, and module-boundary checks pass. [Exact-head CI](https://github.com/paperclipai/paperclip/actions/runs/39997370119) completed successfully, covering the full grouped unit suites, typecheck, build/runtime boot, and E2E shards. The separate serial local `pnpm test:run` is still running and is not claimed as completed. - A later CI shard failed an unchanged email test expecting exactly one task after permission grants. The unchanged-base test passes at normal speed; adding only a 2.2-second pause before granting access reproduces the extra tasks because previously denied deliveries become due for retry. No email code or assertions are changed in this PR. The original failure is retained. The single shard rerun passed: 92 suites and 1,489 tests passed, with one suite and two tests skipped by the existing gates. - CI initially found a route-test double missing the new access helper. The follow-up fixes that fixture and adds event reads to malformed-ID and missing/cross-company checks. All 122 tests across the four changed-path suites pass; a final rerun of the expanded route suite passes all 92 tests. - The first CI run also timed out in the signoff changes-requested handoff while waiting for a reviewer run after a cancelled execution blocker. The focused test passes locally on this source. The same focused test passes three times on unchanged master. Controller-lease cancellation messages appear on both versions. The original CI timeout is preserved as an intermittent, unreproduced failure; its exact cause remains unknown. The signoff shard passes in the final exact-head CI run. - Initial fresh-checkout tests could not start because workspace SDK output and native PostgreSQL library links were missing. Dependency builds and the package's native-link setup corrected those prerequisites. The subsequent focused run passed. Focused command: ```sh pnpm --filter @paperclipai/server exec vitest run src/__tests__/live-events-run-read.test.ts src/__tests__/heartbeat-run-privacy-routes.test.ts src/services/heartbeat/run-state.test.ts src/__tests__/native-observer-replay.test.ts src/__tests__/heartbeat-run-log.test.ts src/__tests__/heartbeat-run-privacy-disconnect-retry.test.ts ``` ## Risks - A missing access field could cause an incorrect allow or denial. Tests exercise current grants, revocation, company scope, and deleted-task bindings through the real consumers. - No successful permission decision is cached. Every delivery and request still checks current database state. - No schema, migration, polling interval, API response, or deployment configuration changes are included. - This reduces bytes for the affected reads. It does not establish a whole-account savings percentage. Hosted transfer measurements remain separate validation after staging deployment. ## Model Used OpenAI Codex, a GPT-6 based coding agent, used repository tools, code execution, and database-backed tests. The session does not expose the exact backend model identifier or context-window size; those values are not guessed. ## 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>	2026-10-23 11:01:06 -07:00
Devin FoleyandPaperclip	5ef783d971	feat: expire idle open issues' worktrees with restore points (#17271 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - #17248 and #17257 let git cache expiration remove a closed issue tree's worktree after saving an encrypted restore point > - Issues that stay open but go untouched for weeks still keep their worktrees forever, so disks keep filling > - This pull request expires those idle worktrees the same way, and has the next run restore its workspace automatically > - The benefit is bounded disk use for stalled open work, with nothing lost when work resumes ## Linked Issues or Issue Description Refs #17248, #17257. Bug report described in-PR (bug report template). What happened? With restore points enabled, expiration only considers worktrees whose whole issue tree has been `done` or `cancelled` for a while. A worktree whose issue stays `todo`, `in_progress`, `blocked` or `in_review` with no activity for weeks is never removed. Expected behavior An open issue's worktree that has been idle long enough is saved to a restore point and removed, and the next run on that issue gets it back exactly. Steps to reproduce 1. Enable git cache expiration and restore points. 2. Leave an issue open with an isolated worktree and no activity for weeks. 3. The worktree is never removed. Paperclip version or commit: `master` at `650581b2f0`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). ## What Changed Expiration (`git-workspace-expiration.ts`): - `isGitWorkspaceExpirationEligible(..., idleCutoff)`: in idle mode the closed-tree conditions are replaced by idle ones. No issue in the tree, and no other issue bound to the workspace, was updated after the cutoff, and no relevant run was created, started or finished after it. Runs of bound issues now count as relevant runs in both modes. Every other check stays, including no live run, recovery action, unsettled finalization, environment lease or running service. - `gitWorkspaceLastActivityAt` returns the latest of those timestamps, sharing the same tree and run scope. - `expireReconstructableGitWorkspace` takes `idleCutoff` and passes it to all three eligibility checks. Reaper (`execution-workspaces.ts`): - For an open tree's isolated git worktree, when restore points and git cache expiration are on and `idleMs` is set, the reaper computes the idle deadline (last activity + `PAPERCLIP_GIT_RESTORE_POINT_IDLE_DAYS`). - Before the deadline, it records the deadline, so the next sweep wakes then. Open trees cause no recurring checks before that. - At the deadline, it runs expiration with a restore point. A kept workspace is retried after an hour, like terminal ones. - An expiration interrupted after archiving (`completed: false`) is resumed by later sweeps even while the tree is open, with a retry scheduled until cleanup finishes. Runs (`heartbeat/environment-selection.ts`): - When a run's issue is bound to a workspace that git cache expiration removed (archived, `workspaceRemoved`), the run reopens it as the agent through `reopenClosedIsolatedExecutionWorkspaceForIssue`, with the restore point applied. - It then clears the reopen fence, since the live run now holds the workspace, and continues with the reopened row. - A failed restore fails the run instead of silently starting a new workspace. - Comments and agent updates on the issue already reopened closed workspaces through the issue routes. Config: `PAPERCLIP_GIT_RESTORE_POINT_IDLE_DAYS` (default `7`, `0` turns idle expiry off). Docs in `doc/recoverable-disk-cleanup.md` and `doc/DEVELOPING.md`. No code comments were added. ## Verification - `pnpm exec vitest run src/__tests__/git-restore-point-expiration.test.ts -t "idle open issues"` (in `server/`): 7 passed, with real repositories and embedded Postgres. - Round trip: an open issue's worktree, idle for 8 days with unsaved work, is skipped without idle mode, expires with a restore point in idle mode, and reopens exactly. - Kept: issue activity 3 days ago, or a run finished 2 days ago, keeps the worktree. - Interrupted: an idle expiration interrupted after archiving is finished by the reaper while the issue stays open, and reopens exactly. - Shared workspace: a recent update on another issue bound to the workspace keeps it, and moves the last activity time. - Reaper: before the deadline the sweep skips the worktree and schedules exactly that deadline; at the deadline it expires it with an active restore point. With idle expiry off, nothing is scheduled or expired. - `pnpm exec vitest run src/services/heartbeat/environment-selection.test.ts` (in `server/`): 14 passed. New cases: a run reopens its expired workspace as the agent, clears the fence with the reopen's generation and binds the reopened row; a failed restore fails the run; a workspace archived for other reasons is left alone. - `pnpm exec vitest run src/__tests__/heartbeat-git-restore-point-resume.test.ts` (in `server/`): 1 passed. Assembled heartbeat journey with no mocked restore: a real worktree with an unpushed commit and uncommitted notes is idle-expired, a queued run executes, the agent runs in the original worktree path with the original workspace id, the commit and notes are back, the workspace is no longer archived with no reopen fence left, and the issue stays bound. Disabling the run-side reopen fails it. - `git-restore-point-expiration-config.test.ts`: the default is 7 and `0` turns it off. - Mutation checks: each of these fails a case: - dropping the idle deadline; - dropping the idle cutoff; - dropping the run activity condition; - not failing the run on a failed restore; - not re-reading the reopened workspace; - not resuming a pending expiration on an open tree; - ignoring bound issues' activity. - `pnpm exec vitest run git-restore-point git-workspace-expiration git-workspace-contents execution-workspaces src/services/heartbeat/environment-selection src/services/heartbeat/workspace-preparation` plus `heartbeat-git-restore-point-resume` (in `server/`): 312 passed. - `pnpm run typecheck` (in `server/`): pass. - Not run: server build and boot smoke. ## Risks - Off unless enabled: requires `PAPERCLIP_GIT_CACHE_EXPIRATION_ENABLED=true` and `PAPERCLIP_GIT_RESTORE_POINTS_ENABLED=true`. `PAPERCLIP_GIT_RESTORE_POINT_IDLE_DAYS=0` keeps restore points for closed trees only. - First run after idle expiry is slower: it waits for the restore, about as long as a reopen. - Failed restore blocks runs: a restore that fails closed (for example a missing restore point) fails each run on that issue until an operator fixes or rebinds the workspace. This is deliberate, so work is never silently continued in an empty workspace. - Kept idle workspaces are rechecked hourly, matching the existing behavior for closed trees that cannot be expired. - Retention: restore points of open trees are not deleted while the tree stays open, as before. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file edits, tests). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-22 20:02:21 -07:00
Devin FoleyandPaperclip	c5ca29dbef	fix(claude): prepare compatible sandbox runtimes during onboarding (#17259 ) ## Thinking Path > - Paperclip connects agent accounts and prepares their execution environments. > - A managed sandbox image can outlive the model defaults shipped by the app. > - Claude setup skipped installation whenever a CLI was already on PATH. > - The selected model then failed its minimum-version check after sign-in succeeded. > - This pull request prepares a compatible private CLI before testing or running it. > - Cloud onboarding also stops asking customers to run inaccessible shell commands. ## Linked Issues or Issue Description What happened? A new managed Cloud stack completed Claude subscription sign-in. Its environment test then failed because the snapshot contained Claude Code 2.1.263, while the selected `claude-opus-5-5` model requires 2.1.280. The screen displayed Manual debug commands that a hosted customer cannot run. Expected behavior Paperclip prepares its managed runtime before testing the selected account. A stale image CLI does not require the customer to upgrade a server package. Failed preparation still blocks hiring. Cloud does not display manual shell debugging. Steps to reproduce 1. Start a managed sandbox with Claude Code 2.1.263 on PATH. 2. Connect a Claude subscription and select `claude-opus-5-5` on the CLI lane. 3. Connect the agent. Installation is skipped because the command exists, then the version gate blocks the hello test. Paperclip version or commit Source baseline: `6204239cfc8c3be79fc185cf3f468ebaa0ab1e3e`. Deployment mode Authenticated managed Cloud with a Daytona named snapshot. The correction also applies to the default CLI in other managed sandbox transports. Related work: Refs #14993 sets model/runtime requirements; Refs #15993 changes native defaults on qualified targets. Neither prepares an outdated default sandbox CLI on this path. Searches found no open duplicate. ## What Changed - Check the actual default CLI against the selected model's existing minimum version. - When a sandbox's default command is outdated, install the exact required npm package into a private versioned workspace prefix. Reuse a compatible private installation. Keep the image's global CLI intact. - Verify the private executable and use that same command for the account hello test and normal CLI runs, with matching command metadata. Probe effort support after preparing that executable so the chosen effort is retained. Keep the model, account, engine and permissions unchanged. - Return safe preparation checks to environment tests and normal run logs, distinguishing installation failure causes without returning raw installer output or credential-bearing URLs. - Exclude provider and Paperclip credentials from the installer environment. Preserve the existing failing version gate if installation or verification cannot succeed. Local, SSH and explicit custom commands remain operator-managed. - Hide Manual debug and legacy operator check hints on Cloud and while deployment metadata is unknown; preserve check messages and details. Retain self-hosted help and the detailed failed checks. Cloud copy asks for a retry instead of asking the customer to repair the environment. - Add subprocess-backed runtime controls, an account-probe regression and mounted Cloud/self-hosted wizard controls. Update development guidance and the affected capability maps. ## Verification - Passed all Claude source suites and the server Claude execution suite on head `c941ae44c22d8dafec0df033a129e39ce4ebd966`: 412 passed, one existing opt-in test skipped. These include the new command/effort ordering, safe installer diagnostics, environment forwarding and run-log regressions. - On final head `0ecae0e9304f495a57524158b3700b8e9bc21cb8`, passed 208 tests across all 174 mounted onboarding wizard tests and 34 Claude execution tests. The failure fixture includes the real command-bearing hint, and execution asserts both metadata command fields agree. - Passed `pnpm -r typecheck`, `pnpm build`, `pnpm check:token-gates`, `node scripts/check-maps.mjs` and `git diff --check`. Full typecheck and build were repeated successfully on final head `0ecae0e9304f495a57524158b3700b8e9bc21cb8`. [Latest-head CI](https://github.com/paperclipai/paperclip/actions/runs/39879208694) is green: 54 checks passed and two skipped, including browser E2E and serialized database suites. - The new runtime controls execute real subprocesses with a controlled installer. They cover an old CLI, an already compatible CLI, failed or ineffective installation, local/custom commands, and an unknown version. The probe regression asserts that the hello call uses the private executable. - A separate non-root local subprocess check installed the real npm `@anthropic-ai/claude-code@2.1.280` package. Its private command reported 2.1.280, the simulated image CLI remained 2.1.263, and a second preparation reused the private copy. This ran on macOS ARM64. It did not use a provider account, send a model prompt, or prove live Daytona behavior. - Attempted `pnpm test:run`. Embedded PostgreSQL initialization failed after five attempts on this Mac with `Postgres init script exited with code null`. The unchanged native-session database cases then failed. Stopped only that full-suite process tree after recording the repeated startup failure. No full local-suite pass is claimed; Linux CI must cover those tests. - The first new subprocess fixture had a quoting syntax error. It was corrected before the passing focused runs. The one-off real-package script first required an ESM extension correction, then passed. Logs retain both attempts. A new execution assertion initially inspected the final sandbox cleanup shell instead of the launched command; it now checks execution metadata. A broader directory selection also picked up generated `dist` tests whose Markdown fixtures are not copied by the build (two ENOENT failures). The explicit source-suite run above passes; no generated-test pass is claimed. - Apex review: 5/5, reviewed final head `0ecae0e9304f495a57524158b3700b8e9bc21cb8`, all five earlier findings addressed and resolved, no new findings. - Merge, deployment and a fresh live Cloud subscription test are still required. No customer account or production runtime was changed by this branch. ## Risks - An outdated sandbox needs npm registry access and up to 120 seconds for one bounded installation attempt. A failed or unverified install continues to block execution. - The versioned package uses sandbox workspace storage. Compatible cached copies avoid repeat installation within that workspace. Existing runtime cleanup and sandbox lifecycle still apply. - The compatible version comes from the adapter's existing model-version contract. This does not add a model fallback or change the selected execution engine. - No schema, credential, permission, workflow or lockfile change. ## Model Used OpenAI Codex, based on GPT-6, assisted with implementation and verification. The exact serving model ID and context-window limit are not exposed in this session. Capabilities used: code editing, shell execution, API inspection and test execution. ## 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>	2026-10-22 18:44:53 -07:00
Devin FoleyandPaperclip	6d44b80a5e	feat: expire closed git worktrees with unsaved work behind restore points (#17248 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Git cache expiration removes a closed issue's worktree only when the remote can reproduce it exactly > - Most closed worktrees hold unpushed commits or uncommitted files, so they are kept forever and disks fill up > - #17238 added restore points (an encrypted save of exactly what the remote cannot reproduce) and #17241 added their lifecycle > - This pull request lets expiration remove those worktrees after saving a restore point, and restores them exactly when the work resumes > - The benefit is bounded disk use for closed work without losing anything a user could need, behind a setting that is off by default ## Linked Issues or Issue Description Refs #17238, #17241. Bug report described in-PR (bug report template). What happened? With `PAPERCLIP_GIT_CACHE_EXPIRATION_ENABLED=true` and dry run off, one instance's last 111 expiration checks removed nothing: \| Skip reason \| Checks \| \|---\|---\| \| `dirty_or_untracked_files` \| 39 \| \| `unpushed_managed_checkout` \| 32 \| \| `live_or_unresolved_consumer` \| 21 \| \| `unique_ignored_files` \| 9 \| \| commit not on the remote \| 10 \| Without expiration, the terminal workspace reaper archives only merged, clean worktrees. Closed issues' worktrees therefore accumulate without bound. Expected behavior A closed worktree whose only obstacle is unsaved work can be removed after that work is saved, and restored exactly if the issue is reopened or work resumes. Steps to reproduce 1. Close an issue whose worktree has an unpushed commit or an uncommitted file. 2. Enable git cache expiration with dry run off. 3. The worktree is never removed. Paperclip version or commit: `master` at `12bb7e1976`. Deployment mode: any. Agent adapter(s) involved: not adapter-specific (core). ## What Changed Expiration (`server/src/services/git-workspace-expiration.ts`): - When it applies: with `PAPERCLIP_GIT_RESTORE_POINTS_ENABLED=true` (default `false`), a worktree that fails the reproducibility check for a relaxable reason is reconsidered once its issue tree has been closed for `PAPERCLIP_GIT_RESTORE_POINT_TERMINAL_DELAY_DAYS` (default `3`). The relaxable reasons are uncommitted or untracked files, a commit not on the remote, reflog or `ORIG_HEAD` history, and ignored `.env` files. A leftover `COMMIT_EDITMSG` still blocks expiration unless it matches a commit in the worktree's reflog, because restore points do not save draft messages. - What still blocks: a relaxed inspection (`inspectGitCacheRecipeForRestorePoint`) keeps every other check. Nested managed checkouts, submodules, special git state, local config and other unique ignored files still prevent expiration. - Capture: inside the existing source and lifecycle locks, a restore point is captured with the #17238 library against a remote-verified boundary (the `HEAD` itself, or its merge base with `origin/HEAD`), then encrypted, uploaded, read back and hash-checked (`git-restore-point-storage.ts`). - Commit before touching disk: it is activated in the #17241 table in the same transaction that archives the workspace with a `paperclip.git-cache-restoration.v2` recipe referencing it, still before anything on disk is touched. - Final check: under the file locks, the worktree must still match the captured snapshot (`HEAD`, index, working tree, modes). Otherwise the existing rollback runs. The rollback now also drops the restore point reference and returns the recipe to v1, so a later restore can never apply a stale restore point over the live worktree; the stored restore point is marked superseded. - Failure paths: the `pending` row is inserted in a transaction that first registers a `git-restore-points` notification. If the upload or read-back fails, the row is marked `superseded` so retention deletes any uploaded object. Nothing is deleted from disk. - Encryption key: restore points are refused (`restore_point_key_not_durable`) on `s3` storage unless the secrets master key comes from `PAPERCLIP_SECRETS_MASTER_KEY`. - Dry run reports `restorePoint: true` candidates without storing anything. Restore (`git-workspace-restoration.ts`, `workspace-runtime.ts`, `execution-workspaces.ts`): - Recipe versions: `readGitCacheRestoration` and `savedGitWorkspaceRestoration` accept v1 without a restore point, or v2 with a valid one. Older servers reject v2 instead of restoring the commit without the saved work. - Before the saved commit is needed: reopening (`restoreGitCacheBase`) and the runtime path import the bundle when the saved commit is missing locally. - After the worktree is re-added: the runtime always imports the bundle, so history-only commits are present again as objects even when the base was rebuilt (they are not recreated as branches), then applies the restore point, verifies the result, and records `appliedAt`. Reopen persists that through a callback, as it already does for saved contents. - Never overwriting: a worktree that already matches is only marked applied. A worktree that diverged from the saved commit's clean state is never overwritten; the restore fails closed and can be retried. Missing, corrupt or expired restore points also fail closed. Retention: the #17241 worker's expiry hook now marks the recipe's restore point expired before its object is deleted. Config and docs: - `server/src/config.ts` adds the two settings; `doc/recoverable-disk-cleanup.md` and `doc/DEVELOPING.md` describe them. - No code comments were added. Not in this PR (follow-ups): - workspaces with nested `.paperclip-repositories` checkouts; - removing idle worktrees of issues that are still open; - starting a fresh workspace with a warning when a restore point has expired. ## Verification - `pnpm exec vitest run src/__tests__/git-restore-point-expiration.test.ts` (in `server/`): 12 passed, with real repositories and embedded Postgres. The cases: - Round trip: an unpushed commit, staged and unstaged edits of one file, a deletion, and an untracked file are restored exactly on reopen, `.env` is dropped, and the restore point is active. Restoring through the runtime path works the same way, and a later run never re-applies over newer work. - Kept: a worktree that is not yet due, one with the feature disabled (today's skip reason), and one whose encryption key is not durable. - Change after capture: rolls back, keeps the worktree, returns the recipe to v1 and supersedes the restore point. - Missing restore point: fails closed, keeps the row archived and unapplied, and fails closed again on retry. - Dry run: stores nothing. - Reproducible worktrees: expire as before, with a v1 recipe. - History-only commits: reopen imports them even after they are pruned from the base. - Draft messages: a draft commit message keeps the worktree. - Upload failure: a failed upload marks the pending restore point for cleanup and keeps the worktree. - Mutation checks: each of these fails at least one case: - removing the pre-deletion snapshot check; - keeping the restore point reference on rollback; - removing the runtime apply; - removing the re-apply guard (the divergence check then fails closed instead of overwriting); - skipping the import for a matching worktree, relaxing the draft message guard, or not marking a failed upload's row. - `pnpm exec vitest run src/__tests__/git-restore-point-expiration-config.test.ts`: 5 passed. - `pnpm exec vitest run git-workspace-expiration git-workspace-contents git-restore-point workspace-runtime execution-workspaces` (in `server/`): 529 passed on the first revision. Two `workspace-runtime.test.ts` cases about remote base refs fail, and they also fail on unmodified `master` on this machine. After the review fixes, the expiration, contents, restore point and execution workspace suites passed again: 222 tests. - `pnpm run typecheck` (in `server/`): pass. - The server builds, the runtime bundle builds, and `scripts/server-boot-smoke.sh node server/dist-runtime/index.mjs` reaches healthy. ## Risks - Off by default: nothing changes unless both `PAPERCLIP_GIT_CACHE_EXPIRATION_ENABLED=true` and `PAPERCLIP_GIT_RESTORE_POINTS_ENABLED=true` are set. Roll out with `PAPERCLIP_GIT_CACHE_EXPIRATION_DRY_RUN=true` first to see which worktrees would receive restore points. - Data at rest: restore points contain source and uncommitted files, encrypted with keys wrapped by the instance secrets key. Losing that key makes them unrecoverable, which is why `s3` storage requires an environment-provided key. Untracked `.env` files are not stored. - Interrupted apply: a crash in the middle of applying a restore point leaves a worktree that neither matches the restore point nor is clean. The restore then fails closed rather than overwriting it, and an operator must reset that worktree to retry. - Rollback: disable the setting. Already-expired worktrees keep their v2 recipes and restore points, so reverting the code would leave those recipes unreadable until restored by a server with this change. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), 1M context, through Claude Code with tool use (shell, file edits, tests, local server builds and boots, read-only measurements on live instances). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-22 16:50:15 -07:00

1 2 3 4 5 ...