PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-10-16 05:17:41 +02:00

Author	SHA1	Message	Date
DottaandPaperclip	3f7b00a8d0	fix: preserve public identifiers in feedback redaction (#16168 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - People rate agent comments and documents to capture feedback. > - Feedback bundles remove credentials and personal information before export. > - The feedback scanner treats ordinary dotted text as JWTs and authentication terms as bearer tokens. > - This pull request checks encoded JWT headers and preserves known authentication terms. > - The benefit is readable feedback context with credential masking kept in place. ## Linked Issues or Issue Description Refs #12309 for the related dotted-identifier false-positive report. This PR fixes the separate feedback scanner. It does not close every case in that report. Related PR: #14318 adds fine-grained GitHub token coverage. It addresses a separate credential form and is not duplicated here. What happened? Feedback exports replace `api.openai.com`, dotted filenames, and public schema IDs with a JWT placeholder. They also replace the words after `bearer` in phrases such as “bearer tokens.” Five-part encrypted JWTs are only partly masked. Expected behavior Keep public identifiers and authentication terms readable. Mask complete credential tokens. Count only text replacements in the redaction summary. Steps to reproduce 1. Pass `api.openai.com` or `Use bearer tokens.` to `sanitizeFeedbackText`. 2. Check that the original text is returned and the redaction counts stay empty. 3. Pass a signed JWT or an encrypted JWT to the same function. 4. Check that the full token is replaced and one JWT replacement is counted. Paperclip version or commit Reproduced in the feedback scanner on master at `5e8e992df2b3d71f82091b7bbf29fd482854d9f5`. Deployment mode Built from source. The defect is in the shared feedback export service and does not depend on deployment mode. ## What Changed - Use the existing JWT header predicate in the feedback scanner. - Match complete three-part and five-part tokens, including direct-encryption tokens with an empty key segment. Accept short token segments in the predicate. - Preserve the closed set of authentication terms already used by the general scanner, including terms inside closing prose delimiters. - Count only replacements that change the text. - Add tests for readable context, credential masking, nested values, and redaction counts. - Document feedback text redaction. ## Verification - Focused redaction and feedback service tests: 89 tests pass across five suites. - `pnpm --filter @paperclipai/adapter-utils typecheck` passes. Full local typecheck, tests, and build were attempted. The kernel killed compiler and test processes at the sandbox memory limit of 4 GB. Serial retries and a capped Node heap still could not complete the server compiler. CI runs the full repository checks. - `git diff --check` passes. - Latest commit `0eb8d3fb4257bb79e67fab615a8299ef69230ad8`: 55 checks passed, including full typecheck, tests, build, and E2E; two optional Storybook checks were skipped. [CI evidence](https://github.com/paperclipai/paperclip/actions/runs/38407932875). Both Greptile findings have regression tests and fixes. [Greptile gives this commit 5/5](https://github.com/paperclipai/paperclip/pull/16168#issuecomment-6146917423), with both review threads resolved. ## Risks - This changes the feedback export matching rules. Public dotted text no longer triggers credential masking by shape alone. - Explicit credential assignments, provider keys, structured secret fields, email addresses, and phone numbers remain masked. Tests cover these cases. - Existing feedback snapshots are not rewritten. No schema change or migration is needed. - The encoded-header check remains a heuristic. It is not a full JWT validator. ## Model Used OpenAI Codex, GPT-6, with reasoning, tool use, and code execution. The runtime identifies the model as GPT-6. It does not expose the exact provider deployment ID or context window size. The earlier patch and this PR preparation were AI-assisted. ## 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-13 09:10:37 -05:00
DottaandPaperclip	561e956266	chore: assign owners to Greptile configuration and rules (#16174 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Repository rules guide code authors and reviewers. > - PR #16172 added rules and Greptile configuration to Git. > - Those directories need named maintainers for future changes. > - This pull request adds ownership for both root directories. > - The entries use the same four maintainers as the existing infrastructure entries. ## Linked Issues or Issue Description Issue type Missing ownership for repository review guidance. Where is the issue? `.github/CODEOWNERS`, for the root `.greptile/` and `rules/` directories. What's wrong? Changes to these directories do not match an explicit code owner entry. Suggested fix Assign the existing four infrastructure maintainers to both directory trees. Refs: #16172. ## What Changed - Add `/.greptile/` and `/rules/` to CODEOWNERS. - Assign `@cryppadotta`, `@devinfoley`, `@nickyleach`, and `@forgottendev` to both entries. ## Verification - `git diff --check`: passed. - GitHub CODEOWNERS validation API on the published branch: zero errors. - Confirm both entries have the same owner list as the existing `.github/**` entry: passed. - Check root and nested paths with Git's ignore-pattern matching: five positive and three negative cases passed. - Application typecheck, tests, and build were not run locally. This changes only CODEOWNERS and does not change application behavior. - Hosted CI and Greptile review are pending. ## Risks Low risk. Future changes in these root directory trees will request review from the existing maintainers. Nested directories with the same names elsewhere in the repository do not match the new entries. ## Model Used OpenAI Codex based on GPT-6. The exact runtime model ID and context-window size are not exposed in this session. Used reasoning, repository inspection, official GitHub documentation, and shell verification. ## 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 (ownership and pattern checks above; application suites were not run) - [x] I have added or updated tests where applicable (direct checks for this ownership-only change) - [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>	2026-10-13 09:05:39 -05:00
DottaandPaperclip	7ac0354b51	docs: track chat channel rules and Greptile configuration (#16172 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Chat channels connect shared task workflows to several platforms. > - Recent refactors moved platform behavior into named channel folders. > - Authors and reviewers need a durable rule that preserves these boundaries. > - Review settings also need version control and an explicit source of rules. > - This pull request adds scoped MDC rules and a staged migration of supported Greptile settings into Git. ## Linked Issues or Issue Description Issue type Missing documentation and versioned review configuration. Where is the issue? Root contributor instructions, chat channel architecture guidance, and Greptile configuration for this repository. What's wrong? The channel folder boundary is established in the refactor but has no focused rule for future changes. Greptile settings and custom context are maintained in the dashboard. Suggested fix Keep canonical rule bodies under `rules/`. Route coding agents through `AGENTS.md` and load matching rules through `.greptile/files.json`. Preserve supported review settings in `.greptile/config.json` and document the remaining dashboard controls. Related work: #15823 and #16080. A search for related rule PRs found no duplicate configuration change. ## What Changed - Add `rules/chat-channel-platform-boundaries.mdc`. Its scope covers `server/src/services/chat-channels/**` and the sibling `chat-channels.ts` entry point. - Define provider folder ownership, shared workflow boundaries, typed dependencies, behavior-preserving extraction, and dispatch exceptions. - Add rule-loading instructions to root `AGENTS.md` and `.greptile/rules.md`. - Add explicit, scoped context references in `.greptile/files.json`. - Record observed review triggers, the Dependabot exclusion, Base tier, High strictness, summary options, fix prompts, status checks, and disabled auto-approval in `.greptile/config.json`. - Move existing PR-description, source-file growth, and repository-specific screenshot guidance into `rules/pull-request-review.mdc`. - Document supported settings, remaining dashboard controls, and the staged cutover. The dashboard was inspected read-only; no settings or saved rules were changed. ## Verification - Parse both MDC headers with Ruby `YAML.safe_load`: passed. - Parse both Greptile JSON files and verify documented field types and observed values: passed. - Verify all four context references resolve to repository files: passed. - Compare scoped MDC globs with the corresponding Greptile scope: passed. - Check ten positive and negative scope cases with Node `path.matchesGlob`: passed. Includes the service entry point, nested provider files, and unrelated runner, connection, and UI paths. - Verify the scope covers all 101 tracked chat-channel files: passed. - `git diff --check`: passed. - Application typecheck, `pnpm test:run`, and build were not run locally. This change contains only guidance and reviewer configuration, and this worktree has no installed application dependencies. No runtime behavior or application tests changed. - Greptile reviewed commit `32647dfd001289a297b9d43c381371da8575df38`: 5/5, eight files reviewed, zero comments. Hosted CI is still running. ## Risks - Instructions depend on agent and reviewer compliance; these files are not deterministic lint rules. - The new MDC directory is explicitly routed through `AGENTS.md` and Greptile. Cursor does not automatically discover arbitrary `rules/` directories. - This preserves the observed High strictness setting, which the dashboard says omits P2 comments. It does not change that review policy. - Dashboard instructions and custom rules remain additive. Their copies were not disabled during read-only inspection. The repository-specific no-screenshot rule explicitly takes precedence over the conflicting older organization instruction. - Draft review, the required 5/5 status threshold, image badges, and other controls without documented config equivalents remain in the dashboard. See `.greptile/README.md` for the inventory and cutover limitations. ## Model Used OpenAI Codex based on GPT-6. The exact runtime model ID and context-window size are not exposed in this session. Used reasoning, repository inspection, shell validation, official documentation, and read-only 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 (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (configuration parsing and scope checks described above; application suites were not run) - [x] I have added or updated tests where applicable (no runtime change; checked configuration directly) - [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-13 08:59:27 -05:00
DottaandPaperclip	5e8e992df2	fix(storybook): reconcile capability associations and map omissions (#16154 ) ## Thinking Path > - Paperclip helps people manage AI agents and their work. > - The feature map describes user capabilities and verification recipes. > - Storybook holds isolated examples of those capabilities. > - Missing catalog links can hide existing examples. > - Some stories also expose shipped capabilities absent from the map. > - This pull request adds verified source associations and three paired map entries. > - Readers can find existing examples without changing their homes or URLs. ## Linked Issues or Issue Description Refs #16052, #16049 and #16046. What existing behavior does this improve? Storybook capability lookup and the feature/agent access maps. Current behavior Seventy capabilities have no example link. Some matching stories already exist. Primary-agent preferences and company decision/fast-response services appear only under broad neighboring capabilities. Proposed behavior Add source-supported links across 34 suites. Keep shared foundations in place while cross-listing them. Add primary-agent, decision-model and fast-response capabilities to both upstream maps. Retain explicit simulation and partial-example limits. Reason and benefit The catalog distinguishes missing associations from missing examples. The upstream map describes three existing product capabilities more precisely. Breaking changes None to product behavior, story exports, folders, sidebar titles or URLs. A shared foundation can declare a reasoned `home: "foundations"` override while referencing related capabilities. ## What Changed - Add 55 references across 34 suites. Replace primary-agent suites' reporting-line association with their own capability. - Add three source-reviewed capabilities and their API/actor boundaries to paired maps. - Preserve the shared Foundations home when cross-listing developer design examples. Add a validation regression test. - Record which exports demonstrate each association and what remains simulated or unverified. - Regenerate the catalog and capability data. Preserve all original 223 authored suites and 2,210 story IDs. Retain the two skill-removal stories added by current master, for 2,212 authored stories in total. - Reduce empty example lookups from 70 of 171 capabilities to 59 of 174. Links do not establish complete capability coverage. ## Verification - Passed: 27 catalog/generator/map tests, catalog validation, map structural checks, token gates and skill validation. - Passed: source inventory comparison preserves all authored files, titles, meta IDs and story IDs. - Passed: repository typecheck/build and Storybook build. Final built index has 2,248 entries and preserves all previous entries, including the two skills stories added by current master. - The broad local repository test run was interrupted before completion to resolve a new master conflict. A complete local suite pass is not claimed; fresh CI passed on the reconciled branch. - Browser: Design links to preserved Foundations stories; company-service sections link settings/history/journey suites; decision SetupToHistory passed 12 interaction steps; primary-agent ReplacePrimary passed four steps. No console errors in selected checks. - Greptile: 5/5 on final commit `805a8af62abe589907e7cc6ca1b415ce1e0cc3c0`, with no findings or unresolved threads. - Final-revision CI passed all 57 checks/statuses, including all eight browser shards, server and Runner tests, typecheck and build. The unchanged Cloud-auth mocked-response race seen on a superseded revision did not recur on the final commit. No test expectations were changed. - New agent-access evidence is source-only. Live provider and agent-credential verification is not established. ## Risks - Suite-level associations can represent only selected states. Notes retain those limits and existing review classifications. - In-memory connection drafts do not prove reload persistence. Resume-failure UI does not prove successful continuation. No-op budget controls do not prove relief or resumption. - Three map capabilities document existing behavior. No permission, API, provider or production component changes. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, code execution and source inspection. The exact runtime 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> canary/v2026.1013.0-canary.7	2026-10-13 08:11:15 -05:00
DottaandPaperclip	aded4197e5	fix: make multiplayer task toasts personal (#16153 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - A company can have several human users and shared agents. > - Live task events currently produce toasts for any user who can read the task. > - This makes unrelated work interrupt other users. > - This pull request checks each user's task participation before it permits a toast. > - Users receive relevant task notifications while company views continue to refresh. ## Linked Issues or Issue Description What happened? Company task activity and agent failures produce noisy toasts for users who have no involvement in the task. Expected behavior A task qualifies when the viewer created it, commented on it, is its assigned user, deliberately acted on it under the Mine rules, or has an explicit user mention in its description or a non-deleted comment. Viewing, agent ownership, responsible-user attribution, and parent participation alone do not qualify. Steps to reproduce 1. Sign in as two users in the same company. 2. Have the second user create and update a task that does not involve the first user. 3. Observe a task toast in the first user's company view before this fix. The duplicate PR search found no existing change for personal task-toast eligibility. ## What Changed - Extract the existing Mine participation predicate without changing Mine behavior. - Compute task eligibility from stored tasks, comments, and run associations after WebSocket access checks. Use an exact indexed comment-mention lookup with `LIMIT 1`. - Add optional `toastEligible` metadata to each viewer's event copy. Keep it off the shared event bus. - Require eligibility for live task activity and task-linked run errors. Suppress generic agent errors. - Continue cache updates for quiet events. Refetch visible comments when authenticated events omit hydration details. Ignore stale socket callbacks after account or company changes. - Document toast semantics and add feature-map and agent-access-map coverage. - Add persisted-data, socket, UI, and authenticated browser regression coverage. ## Verification - Final commit: `1dc4f9402c5883744738cfe236ad00fa0bb5ca4c`. - All 55 current-head checks passed. Two Storybook checks were skipped because this change does not affect that coverage. - Greptile approved this exact commit with 5/5. The security scan passed. Both review threads are resolved. - Local `pnpm build`, `pnpm -r typecheck`, `pnpm check:token-gates`, and `node scripts/check-maps.mjs` passed. - The focused socket/UI suite passed 123 tests. The persisted eligibility suite passed 9 tests, including long history, exact viewer matching, and regex escaping. The existing Mine service suite previously passed 140 tests. - The named browser case `task toasts follow personal involvement in multiplayer` passed against the final commit in an isolated authenticated instance. It used two real sessions, real WebSocket delivery, and persisted tasks, edits, comments, and mentions. It verified quiet unrelated activity, viewing alone, first and historical mentions, own-action suppression, visible-task suppression, and live cache refresh. - A prior-head server shard passed its single rerun after a fixture-cleanup deadlock. The final-head CI run passed without a rerun. - The broad local run remained in progress when CI completed the full test suite. Local focused checks and CI provide the completed test evidence. ## Risks - This intentionally reduces live notifications. A new client stays quiet against an older server that omits eligibility. - Eligibility queries add work to live event delivery. A lookup failure suppresses the toast and still delivers the authorized event. - Deleted mentions cease to qualify unless another participation rule applies. Historical comment authorship retains the existing Mine behavior. - No database migration or notification-settings change is required. ## Model Used OpenAI Codex with GPT-6 assisted with implementation, tests, documentation, and PR preparation. It used repository tools, shell commands, and browser automation. The runtime did not expose an exact 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-13 08:09:19 -05:00
DottaandPaperclip	2ad36f4ff2	Fix skill source removal with a keep-or-delete choice (#16150 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - GitHub sources import skills and keep their updates together. > - Disconnect only disabled a source and kept its read-only imports. > - A disabled source could not be removed or imported again. > - Removing a source needs an explicit decision about its imported skills. > - This pull request removes the source after the user keeps editable copies or deletes the imports. > - Existing disabled sources use the same removal flow. ## Linked Issues or Issue Description Refs #15731, #14713. What happened? Disconnect left the repository on Sources. Its Disconnect action was then disabled. The saved repository still blocked a new import. Expected behavior Remove the repository from Sources. Require a choice to keep editable copies or delete its imports. Allow removal of sources that are already disconnected. Steps to reproduce 1. Import a repository in Skills → Sources. 2. Choose Disconnect source. 3. Observe the disconnected row and disabled removal action. 4. Try to import the repository again. Paperclip version or commit `d67e3507b2`. ## What Changed - Add one confirmation with a required keep-or-delete choice. - Remove the source and entries, including legacy disabled sources. - Keep complete editable copies in My Skills, including shared repository files and executable modes. Preserve skill IDs, keys, versions, and agent assignments. - Delete imported skills and source in one transaction with its activity record. Check policy for every linked skill, including deselected entries. Reject deletion of skills still used by agents. - Fence removal with the source revision. Reload stale confirmations and require a new choice. Prevent an in-flight refresh from restoring removed imports. - Reject incomplete legacy copies with a recovery message. Lock copied skill rows against concurrent deletion and check publication succeeded. - Add regression tests and production-page Storybook examples. Make an initially unselected radio-card group keyboard accessible. ## Verification - Workspace typecheck and build passed. Final affected server/UI typechecks passed. - Focused server, UI, and API suites passed: 114 tests initially. After review fixes, all 21 source persistence and 58 route authorization tests passed, including the complete repository copy regression; affected server/UI typechecks and token gates passed again. - Design token gates passed. - Real isolated app: imported a public repository, assigned bro to the CEO, verified that deletion reports the assignment, kept an editable copy, observed the source disappear, opened the copy in My Skills, saved an edit, and refreshed. The assignment remained. Re-imported the same repository, deleted its new unused import, and verified the original editable copy and assignment remained. No model tasks ran. - Full local Vitest was attempted but terminated with exit 137 before completion; it is not counted as a pass. Current-head sharded CI is pending. Greptile reviewed the current head at 5/5 with no new actionable comments. The final workspace build passed again. - Storybook catalog aligned. The legacy removal example was inspected in the browser; the Delete choice enables removal. - Storybook: Skills / GitHub-synced skills / Sources · Disconnect source and Sources · Remove disconnected source. ## Risks - DELETE of a skill source now requires the saved revision and an explicit copy/delete choice. Old callers must update their request body. - Deletion removes imported skills and their records. Assigned skills must be detached first. - Incomplete legacy versions must be refreshed before keeping copies; removal does not silently discard supporting files. - Copies intentionally stop receiving upstream updates. Their IDs and keys remain stable for assigned agents. - No database migration. Copy writes use new managed directories and clean up on failure. Delete restores quarantined files before releasing publication locks on failure. ## Model Used OpenAI GPT-6 through Codex, configured model `gpt-6-astra`. The runtime does not expose the context-window size. Used shell tools, code editing, tests, and browser interaction. ## 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-13 07:53:13 -05:00
DottaandPaperclip	df06df2306	fix(slack): allow direct messages without at-mentions (#16151 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Slack connections let people start and continue agent tasks. > - The Require at-mention setting currently applies to channels and direct messages. > - A person who sends a direct message has already selected the agent. > - This pull request exempts direct messages from mention checks, including queued work. > - People can talk normally in DMs while channel messages keep the configured mention rule. ## Linked Issues or Issue Description Refs #15612, which introduced the Require at-mention setting. Searches found no duplicate PR for the DM exemption. What happened? With Require at-mention enabled, a plain Slack DM does not start or continue agent work. New Slack connections enable the setting by default. Expected behavior Direct messages do not need an at-mention. Top-level DM replies remain top-level. Channel messages and channel thread replies still follow the saved mention setting. Steps to reproduce 1. Enable Allow direct messages and Require at-mention on a Slack connection. 2. Send a plain DM from an authorized sender. 3. Confirm the agent responds without an at-mention. Send a plain follow-up and confirm it also works. 4. Confirm unmentioned channel messages remain filtered when Require at-mention is enabled. 5. Disable Allow direct messages and confirm new DMs remain blocked. Paperclip version or commit Source baseline: `eb06c9fedd`. Deployment mode Built from source. Automated tests use disposable local Postgres and provider fixtures. This change has not been deployed or retested in live Slack. ## What Changed - Exempt DMs at inbound admission, task mutation, work authorization, and heartbeat queue claim. - Keep channel mention checks and all existing sender, endpoint, and destination checks. - Update regressions for new connections, follow-ups, deferred delivery, and coalesced queued messages. - Clarify the Slack settings copy, connection documentation, and verification maps. - Refresh the affected Storybook review references after source inspection. ## Verification - Passed 55 Slack and durable scheduler tests with Vitest on the current rebased commit, including admission through the extracted inbound module. - Passed `pnpm -r typecheck` and `pnpm build` on the rebased PR commit. - Passed token gates and map checks. - Passed Storybook catalog validation after rebase: 223 files and 2,210 stories. - Full local `pnpm test:run` was stopped before completion after three failures in the unchanged tool-access suite. All 418 tests in that suite passed in a standalone rerun. The focused regressions passed; full GitHub CI remains the merge gate. - Greptile reviewed commit `b0293fa6571403c5e01c30bb7b5fcc5e91b88c97`: 5/5, with no findings or unresolved review threads. All 55 GitHub checks passed on this commit; two optional Storybook jobs were skipped. - No live Slack messages were sent during implementation verification. ## Risks Existing Slack connections now accept authorized plain DMs even when Require at-mention is enabled. Allow direct messages and sender authorization still apply. Queued DM work follows the same exemption. Channel behavior and DM reply routing are unchanged. No schema or migration change is required. ## Model Used OpenAI GPT-6, running as Codex, with reasoning, tool use, and code execution. The runtime does not expose a more specific 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-13 07:40:46 -05:00
DottaandPaperclip	fc3b15537b	fix(runner): match call_api to existing agent REST permissions (#16040 ) Route native call_api through existing agent REST permissions. Preserve admitted credentials across restarts, protect sensitive replies and private snapshots, and compare saved completion with provider history through the same redaction projection. Add permission, privacy and recovery regressions and update the access map and run-log guide. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:34:15 -05:00
DottaandPaperclip	eb06c9fedd	refactor(server): split chat channel workflows into provider and shared modules (#16080 ) Move provider operations into channel folders and shared chat work into named interaction, setup, admission, delivery and publication workflows. Consolidate reviewed PRs #16085, #16089, #16096 and #16105. Preserve upstream execution-default and recovery behavior. The main service is 7,917 lines. All 55 current-head CI checks pass, with two optional Storybook skips. Greptile is 5/5 with no findings. All 1,294 current chat integration cases, repository-wide typecheck and build pass locally. Broad local tool-route timing/socket failures are recorded in the PR. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:26:32 -05:00
DottaandPaperclip	60bc0d5fee	fix(release): run native builds and canary smoke after skipped channels (#16149 ) ## Thinking Path > - Paperclip lets people manage AI agents for work. > - Published packages need the native runner artifacts from their exact source. > - The release workflow selects one channel and deliberately skips the other channels. > - The native producer used an implicit success condition across those skipped dependencies. > - The merged-source release selected native artifacts but skipped their build and canary publication. > - This pull request makes the existing producer and canary smoke conditions explicit. > - Successful source selection, artifact verification and cancellation checks still apply. ## Linked Issues or Issue Description Refs #16028. What happened? [Release 38389963483](https://github.com/paperclipai/paperclip/actions/runs/38389963483) passed source selection, then skipped native production, canary publication and onboarding smoke. The exact source script requires native artifacts; the API does not expose the source job outputs. The registry canary still points to an older source. Expected behavior The selected release channel builds its required native artifacts, publishes its verified package, then runs the exact-version onboarding smoke. Skipped inactive channels must not suppress these jobs. Steps to reproduce Inspect the linked master-push run at `d67e3507b23041212fa26302ce6de078c5ebcc05`. Compare the successful source job and exact source script with the three skipped jobs. The two existing workflow contract cases also fail against the original conditions. Paperclip version or commit `d67e3507b23041212fa26302ce6de078c5ebcc05`. Deployment mode GitHub Actions release workflow. ## What Changed - Require `!cancelled()`, successful source selection and `required=true` for native production. - Require `!cancelled()` and successful publication for canary onboarding smoke. - Extend the existing workflow tests for selected channels, skipped ancestors, missing outputs, failed jobs and cancellation. ## Verification - The two affected contract cases fail before treatment and pass after treatment. - Focused source controls cover 28 producer and five smoke condition combinations. - Independent source review found no changes to source, trust, artifact, channel, permission or publication gates. - These tests check source predicates. Actual hosted routing and publication must still pass after merge. - Full existing release suite: 70/70 pass. Existing source-verification neighbors: 20/20 pass. - Workflow structure passes actionlint. Full shell lint reports five hints in unchanged commands. - Full hosted checks and fresh Greptile review are pending. ## Risks The producer serves all release channels. The explicit source-result and required-output checks retain each channel's admission gates. Cancellation still prevents new work. This does not change runtime code, packages, agent selection, or stored configurations. [GitHub documents the implicit status check](https://docs.github.com/en/actions/reference/workflows-and-actions/expressions#status-check-functions) and [skipped dependency behavior](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs). ## Model Used OpenAI Codex, based on GPT-6, with reasoning and code tools. This session does not expose a verifiable exact 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 - [ ] 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> canary/v2026.1013.0-canary.6	2026-10-13 07:12:11 -05:00
DottaandPaperclip	fd61dc1dd5	docs(skills): distinguish Paperclip verification targets (#16145 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Verification must show which runtime and user journey passed. > - The existing skill centers on an empty instance launched from source. > - Seeded data, reused databases, published packages, and hosted stacks prove different outcomes. > - This pull request makes the target and starting conditions explicit. > - It routes deployment to private Cloud skills and keeps feature checks in Verify Paperclip. ## Linked Issues or Issue Description Issue type Missing documentation. Where is the issue? `.agents/skills/verify-paperclip/SKILL.md`. What's wrong? The skill does not distinguish source development, npm installation, staging, and production. It also needs to distinguish fresh onboarding from seeded or reused data and make platform scope explicit. Suggested fix Add target selection and focused references. Preserve the existing empty-instance helper. Name the private Cloud deployment skills as a separate prerequisite when deployment is requested. No duplicate documentation PR was found in the open-PR search. ## What Changed - Record artifact, environment, starting data, platform, and journey before testing. - Document dev servers, fresh instances, seeded/reused test drives, and cloned worktrees. - Separate exact-version canary and stable npm verification from source and Cloud evidence. - Document staging and production checks and route deployment to `deploy-paperclip-stack` or `deploy-cloud-harness` in the private Cloud repo. - Limit local ownership helpers to instances created by their launcher. ## Verification - Current-head GitHub CI: 55 passed, 2 skipped, no failures. Typecheck, tests, build, and the aggregate gate passed. Greptile: 5/5, all threads resolved. - Skill validator: passed. - Relative Markdown file links: passed across the changed skills and references (29 links in final validation). - `python3 -m unittest discover -s .agents/skills/verify-paperclip/tests -v`: 2 passed. - `node scripts/check-maps.mjs`: passed (structural coverage only). - `git diff --check`: passed. - `pnpm -r typecheck`, `pnpm test:run`, and `pnpm build`: attempted; blocked by missing workspace dependencies (`node_modules`, Node type definitions, and the checkout tsx entry point). These are not passing full-suite results. - Existing published-launcher test attempt was blocked by sandbox loopback permissions; it does not provide package-install evidence. - Reviewed commands against development docs, release workflow, and current Cloud runbooks. No live deployment, publication, or production mutation was performed for these documentation changes. ## Risks - Low runtime risk: only skill documentation changes. - Private deployment skills require access to the Cloud repo and must be available before that handoff works. The verifier reports the prerequisite when unavailable. - Workflow changes can make command guidance stale. The skills direct readers to maintained workflows and runbooks before use. ## Model Used OpenAI GPT-6 via Codex, with reasoning, file editing, shell execution, and GitHub CLI access. The runtime does not expose a more specific 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 and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (the focused ownership suite; full-suite limits are listed above) - [x] I have added or updated tests where applicable (no runtime change; existing tests retained) - [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-13 07:02:37 -05:00
Dotta Paperclip copilot-swe-agent[bot]	9bd820e687	feat(storybook): mirror the complete feature-map index (#16052 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The feature map describes its user-facing capabilities and verification recipes. > - Storybook provides isolated UI examples for those capabilities. > - The previous organization showed only features with primary story suites. > - This pull request derives the complete Storybook index from the upstream map. > - Readers can find the same features in both places and see related examples or explicit gaps. ## Linked Issues or Issue Description Refs #16046 and #16049. What existing behavior does this improve? Storybook navigation and the downstream feature catalog. Current behavior The sidebar has 28 primary feature homes. The feature map lists 35. The main guide groups suites alphabetically by area slug. Related examples can live under a different feature. Proposed behavior Use the feature map's eight sections and 35 features in the same order. Give each feature an Overview page with all its capabilities, related example links, and missing-example messages. Keep shared foundations outside the product index. Preserve all existing stories and URLs. Reason and benefit Readers can move between the feature map and Storybook without learning a second index. A feature without cataloged examples remains visible. Breaking changes None to existing story IDs or product behavior. Storybook start and build now reject stale generated feature pages and ordering. Run the catalog generator after upstream changes, inspect the output, and review affected source fingerprints. ## What Changed - Generate 35 feature Overview stories and capability data from the upstream map. Generate the inline sidebar order required by Storybook. - Replace the main guide with the full ordered feature index and search. Link all related suites from feature pages, even across primary homes. - Preserve all 223 authored files, 2,210 story IDs, and the existing docs ID. Keep status, implementation, and fixture classifications visible. - Put the generated Markdown catalog in feature-map order. Keep generated guides outside example counts. - Update maintenance and review skills, documentation, and generator tests. Keep the feature map independent of Storybook. ## Verification - Passed: 16 catalog and generator tests; map checks; token gates; both skill validators. - Passed: `pnpm -r typecheck`, `pnpm build`, and the Storybook build. - Built-index comparison preserved all 2,211 previous entries and added only 35 feature overviews. Feature order matches the map. - Browser: inspected the complete index and sidebar, searched for Goals, opened its overview, and followed a related suite under Projects. The original suite renders. - Passed: all 8,170 UI tests in 728 files. Browser checks also covered empty search, capability-ID search, missing-example pages, the original editable-text bookmark, the CLI sidebar label, and searching/opening shared foundations. - The broad local `pnpm test:run` was stopped after a failure in the unchanged GitHub chat test `authorizes description edits as the editor, never inheriting the original author's access`. That exact test passed alone without code or expectation changes. A complete local repository suite pass is not established. - Original revision CI passed after one runner retry. The merged revision `5ca01c70716f23974680a8019ddc613035d11bc4` passed fresh CI. Local UI typecheck, catalog checks, 16 generator tests, map checks and token gates pass. - Greptile: 5/5 on final commit `5ca01c70716f23974680a8019ddc613035d11bc4`, with all findings resolved. - Master merge: inspected source drift in 61 catalog entries and regenerated INDEX, preserving upstream notes. Marked the sidebar suite that mounts IssueDetail unreviewed for the new activity query; recorded limits for composer and channel-default changes. No stories removed. - Final Storybook build passed. Browser filename searches for `new-task-composer` and `forms-editors` return the expected feature and shared example. - No visual-baseline or full production acceptance claim. The deeper authored scenario groups remain intact. ## Risks - The parser depends on the feature-map Markdown contract. It rejects unknown index rows, omitted feature recipes, and unexpected generated files. - A suite can reference several capabilities. A link proves catalog association, not complete behavior coverage or production parity. - Storybook treats `/` as a folder separator. Sidebar labels use a comma for that character; the guide and page headings retain the upstream name. - No database, API, authorization, or production component changes. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, code execution, and browser inspection. The exact runtime 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> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>	2026-10-13 07:01:29 -05:00
DottaandPaperclip	d67e3507b2	feat(runner): qualify Codex platform packages and cache hosted builds (#16028 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Native execution needs a compatible installed daemon and provider dependency. > - The Codex-default work found missing platform packages and clean-install startup failures. > - Release builds also repeat dependency compilation and run preparation serially. > - This prerequisite packages four daemon targets and verifies installed native startup. > - It also caches hosted Cargo dependencies and overlaps JavaScript preparation with compilation. > - Agent creation defaults and experimental gates stay at the current master behavior. ## Linked Issues or Issue Description Refs #15683. Refs #15555. Refs #15422. Refs #15926. Refs #15932. Extract runtime and installation support from #15683. This prerequisite has 65 changed files. Creation, onboarding, imports, UI runner selection and graduation remain in the dependent PR. Feature/access maps and the Storybook source catalog stay synchronized. Existing agents keep their execution choices. ## What Changed - Correct the existing runner test fixtures. Reserve owned credential quorum listeners through the existing bounded fixture helper. Keep foreign listeners intact, run actual credential staging once, and preserve its rejection and unchanged-auth assertions. Reuse the durable-resume outer-limit correction. Wait for actual warm-completion and held-authorization callback entry under the existing recovery deadline and surface early request errors. Preserve every semantic assertion. - Retain bounded installation failure diagnostics through the existing qualification receipt upload. Keep the original error, 10-minute deadline and all success checks. - Keep startup ownership until credential preparation and registration drain. Reject duplicate and post-close startup/resume work. Observe shutdown during normal and adopted authentication readiness. Preserve the primary failure and retain private state when cleanup is unconfirmed. - Package Linux x64/ARM64 and macOS Apple Silicon/Intel daemons. Verify target headers, source identities, manifests, and hashes before assembly and installation. - Reuse the existing release producer/consumer workflows. Cache Cargo dependencies by target, OS, compiler, lockfile, and contract inputs. Rebuild workspace binaries. Permit trusted cache writes only for canonical exact-source master pushes. - Overlap JavaScript preparation with native compilation. Join both commands and failure/cancellation cleanup before artifact verification. - Preserve shell positional arguments in the shared SSH runner and apply environment assignments correctly. Reject environment option keys. Six before/after controls and two real SSH subprocess paths pass with zero provider calls; this fix lands before both Codex and Claude defaults. - Admit verified suspended SSH backups during cold controller continuation, using the same full-scope, integrity and lifecycle checks as sandbox targets. Two positive SSH cases fail before; all 14 positive/negative matrix cases pass afterward. Active ownership and corrupt/malformed/nonempty state remain rejected. - Record measured sandbox platform facts through the existing explicit environment probe. Bind facts to the company, effective provider configuration, immutable OCI image and actual captured image binding. Check the returned cleanup receipt. Reject client-authored proof and stale or named boot identities. Creation and discovery allocate nothing. Preserve connection-only behavior. - Resolve the actual remote Codex target and preserve same-host development overrides. Preserve runtime artifact verification. Use actual protocol/model compatibility rather than a numerical CLI version fence. - Resolve the installed Codex login dependency on 64-bit Linux and Mac independently of the daemon libc baseline. Preserve account homes and safe errors. - Fix actual clean-install TOML table comparison. Preserve strict semantic checks, comments, private writes, and malformed-input rejection. Preserve primary startup failures and bounded cleanup. - Document GNU libc 2.39+ and stock Ubuntu sandbox prerequisites. Qualify ARM startup with a scoped distribution profile and unchanged global restrictions. Preserve Windows and Alpine deferral. - Preserve selected and saved native Codex reasoning effort in the existing UI builder, while excluding it from other providers. This small shared correction prevents import edits higher in the stack from dropping effort. - Reuse existing installed-package checks and assertions. Paperclip tarballs contain no Codex native payloads. Official npm dependencies supply the consumer's Codex binaries. All Docker and native builds stay remote. ## Verification Candidate: `271d434c170e74bdedde65d0b13059a55419c943`. It includes current master `e168512f7bdbb6af6ea01954c6d7ed80b91e903e` and preserves prior candidates through ordinary commits. Current [full CI](https://github.com/paperclipai/paperclip/actions/runs/38346601686) is successful on attempt 2. GitHub reports 54 successful checks and four conditional skips, including required verify and browser aggregates, workspace typecheck/tests/build, Linux DB controls, both runner shards and [isolated native compilation](https://github.com/paperclipai/paperclip/actions/runs/38346601609). Fresh current-head Greptile is 5/5 with all four threads resolved. The passing build's clean Grok/Codex report records CI merge source `7a82a37438e6e448abc7cc5caa60dc2519a97be0`, 18 installed packages, omitted Codex payloads, official host-only npm dependencies and zero provider calls. Pi setup and its no-prompt lease verification also pass. The first attempt's single 60-second Node archive download timeout remains retained; its DNS/TLS/download cause remains unknown. One unchanged-source retry was requested through the normal Build-job dialog with debug logging disabled. GitHub's attempt 2 graph reports the other CI jobs as well; no second retry or source/deadline relaxation was made. The [final exact-source package campaign](https://github.com/paperclipai/paperclip/actions/runs/38347027535) is successful on literal `271d434c170e74bdedde65d0b13059a55419c943`. It passes all four native producers, public Linux package assembly and clean installed consumers on Apple Silicon, Intel Mac and Linux ARM64. The nine qualification-mode skips are intentional; full CI above covers their ordinary gates. Native builds and Docker assembly ran remotely. The predecessor [`dae808` package campaign](https://github.com/paperclipai/paperclip/actions/runs/38342104102) remains literal historical evidence. Only tests and the dated record differ from that source; runtime, package and workflow code is unchanged. The reused credential fixture correction passes all 42 canonical Node 24 controls with synthetic data and independent matching-source review, and the current hosted runner shard passes. Production credential behavior is unchanged. Merge hold: current-source CI, fresh 5/5 review and exact-source package qualification pass. Actual code-owner approval and normal protected merge remain pending. No slice has merged or deployed. GitHub CLI authentication needs refresh; the normal signed-in embedded GitHub UI provided this status without credential workarounds. - The master merge preserves both Storybook source-review appendices and the guarded test-home cleanup. All six existing cleanup controls pass without skips. Master's isolated-home helper/test/setup are byte-identical. The two existing whitespace lines in master's unrelated privacy test remain outside this PR's diff. - Canonical Node 24 passes all 24 existing public-install helper tests. Three narrow added cases prove bounded/redacted failure metadata, symlink exclusions, original exception identity, failed diagnostic writes and no false failure on success. The Mac installer now uses `--timing`; at most two 16 KiB tails and 32 structured entries per tail enter the existing receipt upload. Raw argv, URLs, environment, error text and stacks are omitted. A failed receipt explicitly remains FAILED/unqualified/runtime-not-attempted. The 600,000 ms install deadline and every real package/hash/payload/lock/lifecycle/runtime oracle are unchanged. - Canonical Node 24 reproduces the durable-resume outer timeout under controlled fake latency. Only its outer test limit changes to 15 seconds; internal 500 ms/5 second deadlines and usage/effect assertions remain. Controlled warm-recovery and before-bootstrap authorization scheduling delays reproduce their callback polling failures, while the explicit entry signals pass. Early recovery errors surface unchanged. Independent review is clear. Historical mock binaries support the fixture controls; fresh full hosted CI remains decisive. The original hosted callback failure cause is inconclusive. - The composed runner/surfaces/server/E2E TypeScript checks pass. Map checks pass 35 areas/171 capability IDs. Token gates pass. The existing Storybook catalog passes 223 files/2,210 stories; story IDs and classifications remain intact. The current master had 25 inherited stale fingerprints from three changed map recipes. Only those guarded fingerprints and a source-only review note change; all 92 non-map story/component/fixture inputs remain unchanged. Existing classifications are retained. This proves source structure, not visual or live acceptance. - The 65-file contribution audit has no code file crossing from below 1,000 lines to above the limit. Earlier comment cleanup preserves executable emissions, parsed workflows and action pins. Independent cleanup/catalog and three-file reporting reviews are clear. No new workflow, suite, grader or local native/Docker build was added. Prior `dae808` gate evidence: fresh Greptile is 5/5 with four resolved threads, isolated native compilation and the browser aggregate pass. Its first runner shard passes the previous two corrections but fails a different held-authorization cell at the implicit one-second polling deadline. It records 1,672 passes/one failure/three skips. This candidate applies the verified entry-signal correction without changing production deadlines or any semantic assertions. Its original hosted cause remains inconclusive until fresh CI. Previous-source evidence, kept literal: the [exact `16a532` package campaign](https://github.com/paperclipai/paperclip/actions/runs/38338806076) passes all four native producers, public Linux package assembly, Apple Silicon, Intel Mac and Linux ARM64 installed consumers. Its fresh review is 5/5 with all four threads resolved. Full CI records 52 successful checks, four conditional skips and the two fixture failures corrected here. This is not a green full-CI candidate or proof for the new source. `64c074fb8da1b31f8d6042c4fef48dc4164e759b` passed [full CI](https://github.com/paperclipai/paperclip/actions/runs/38332726938), 54 checks/four conditional skips, [isolated native compilation](https://github.com/paperclipai/paperclip/actions/runs/38332726787/job/115085895328), and fresh Greptile 5/5/all four resolved threads. The hosted transport suite passed 246 tests and startup trust passed 22, closing that source's local fake-binary limitation. These are historical after reconciliation. The [previous exact-source package campaign](https://github.com/paperclipai/paperclip/actions/runs/38332921463) built all four platform daemons and passed public Linux package assembly plus Apple Silicon and Linux ARM64 installed consumers. Intel Mac failed: its initial scripts-disabled npm install timed out before lifecycle/runtime assertions. The underlying download/resolution/host cause is unknown because the old helper deleted the npm logs. This is the concrete baseline for the diagnostic change. The failed campaign remains failed; no all-platform signoff or automatic retry is claimed. The earlier `a200495` [four-target campaign](https://github.com/paperclipai/paperclip/actions/runs/38283695248) and [scoped ARM qualification](https://github.com/paperclipai/paperclip/actions/runs/38291535914) remain component evidence. Cargo restores were cold misses; no warm-cache speedup is claimed. Paperclip tarballs contain no Codex payloads. Official npm dependencies supply Codex on the user's platform. Current-source full workspace typecheck/tests/build, Linux DB controls, static/Rust/native tests, all browser shards and exact-source package consumers must pass. New-agent defaults and final managed onboarding belong to #15683. Actual private Cloud composition, warm/cold signup, task/follow-up and rollback compatibility remain later release gates. Source audits found that ordinary managed onboarding does not run the saved platform probe and Cloud distributes named snapshots without a verified final boot-image binding. These dependent release blockers remain open; prequalified E2E fixtures do not close them. Master adds task-workspace migrations; the final image/migrator and previous-image checks must include them. ARM paid task/follow-up and ordinary OS APT installation are not proven. ## Risks - Multi-target packages require source and header agreement. Missing or mismatched artifacts fail explicitly. Existing execution choices remain unchanged. - Linux requires GNU libc 2.39+ and compatible sandbox prerequisites. The scoped hosted ARM preparation does not qualify arbitrary containers or kernels. Windows, 32-bit ARM, and Alpine remain deferred. - Only dependency crates are cached. Preview jobs cannot write trusted caches. Concurrent command cleanup must preserve the primary failure. - Native-free Paperclip packaging retains official Codex npm dependencies. No Codex payload bundling, schema migration, automatic agent migration, or production deployment is included. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools, code execution, and parallel agents. The exact serving model snapshot 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 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-13 06:24:07 -05:00
Dotta	4a641d0980	fix(ui): default human task replies to the latest assigning agent (#15594 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Tasks let agents ask a person for input. > - The reply composer needs a useful default recipient. > - A recent comment does not identify the agent that assigned the task. > - The old fallback can select the person who is writing the reply. > - This change uses the latest agent assignment and keeps manual choices. ## Linked Issues or Issue Description What happened? When an agent assigns a task to a person, the reply composer can select that person or a different commenter. A data refresh can also replace a manual selection. Expected behavior For a task assigned to the current person, select the latest agent that assigned it to them. If no such assignment exists, use the latest other commenter. If neither exists, leave the recipient empty. Keep explicit choices during refreshes. Steps to reproduce 1. Have agent Alpha assign a task to a person. 2. Assign it to agent Beta, then have Beta assign it to the same person. 3. Open the task as that person. 4. Check that the reply composer selects Beta. 5. Select another recipient. Refresh task data. Check that the selection stays. Related work: #15091 shares task composer controls. This change fixes recipient defaults. ## What Changed - Read real assignment changes from REST and native runner task activity, in time order. - Record human assignee fields in native create and reassign activity. - Ignore unchanged assignment fields and assignments to other people. - Use the assigning agent before comment hints for human-owned tasks. - Connect the suggestion to current and classic task composers and pipeline replies. - Keep manual selections when suggestions change. - Add regression tests and document the fallback. - Use tasks with no assignee in the attachment receipt tests. This keeps the tests on the comment route. Dismiss announcements through the real UI. - Record human and agent assignees in REST creation receipts. Include child creation in the assignment history resolver. ## Verification - Focused tests cover assignment order, creation, other recipients, unchanged fields, fallback, and manual selections. - Browser fixture uses the real composer and assignment resolver. It selects Beta and keeps a manual human selection after history refresh. - Passed: 223 focused tests across four suites. - Passed: `pnpm --filter @paperclipai/ui typecheck`. - Passed: `pnpm --filter @paperclipai/ui build`. - Passed: `pnpm check:token-gates`. - The initial CI run passed full build, typecheck, Rust, unit tests and seven E2E shards. The attachment shard exposed tests that relied on the old self-selection default. The tests now select the recipient explicitly. - Native assignment regression tests and resolver tests pass: 40 tests. - Attachment E2E suite: 10 passed; one page-load timing failure passed on an isolated rerun. All 11 cases passed across the suite and rerun. - Previous full CI passed at `cc7ed05`. New CI must pass on the current head. - Latest local checks: 16 resolver tests and 7 workspace policy tests pass. REST creation audit tests cover both creation routes. - The latest browser check could not start. The UI build exceeded the local memory limit (exit 137). Full typecheck, tests, build, and browser checks will run in CI. ## Risks - Old activity rows without previous assignment values cannot prove a reassignment. They use the comment fallback. - An empty fallback requires the person to choose a recipient or use the existing no-assignee flow. - No database or API schema changes. ## Model Used OpenAI Codex, GPT-6. The session does not expose an exact model build or context window. Used code editing, shell tools, tests, and browser verification. ## 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 Final validation at `f83f2f6`: 55 checks passed. Two optional Storybook checks were skipped. All browser shards passed. Both review threads are resolved. Classic attachment tests use the real no-assignee confirmation. nightly/v2026.1013.0-nightly.0 canary/v2026.1013.0-canary.5	2026-10-13 00:56:15 -05:00
DottaandPaperclip	d837b65be8	refactor(server): move provider setup, inventory and delivery into channel folders (#16058 ) Consolidate the ten reviewed provider-folder extractions. Preserve the verified source tree and current master changes. Co-Authored-By: Paperclip <noreply@paperclip.ing> canary/v2026.1013.0-canary.4	2026-10-13 00:26:33 -05:00
DottaandPaperclip	7d7f55e4be	fix(apps): show user avatars and center access rows (#15577 ) ## Thinking Path > - Paperclip helps people manage AI agents and their access to apps. > - The app access page shows people with linked chat accounts. > - The identity response omitted the user's saved image. > - The row placed the avatar beside only the first name line. > - This change returns the image and centers the avatar beside both name lines. > - People can recognize linked accounts and still see initials when no image is available. ## Linked Issues or Issue Description What happened? The app access page showed initials even when the linked Paperclip user had a profile image. The avatar was above the vertical center of the Disconnect button. Expected behavior Show the linked user's saved image. Center it beside the Paperclip and chat names. Keep initials when no image is available. Steps to reproduce 1. Link a Slack account to a Paperclip user with a profile image. 2. Open the app's Access tab. 3. Inspect the person's avatar and the two name lines. Searched public issues and pull requests. No duplicate fix was found. Related avatar work in #15095 concerns agent uploads, not linked user profiles. ## What Changed - Return `paperclipUserImage` from the chat principal service and declare it in the API and client types. - Use the shared avatar primitives and center the avatar beside the full name block. Keep full names available in hover text. - Add image and initials examples to the existing Storybook access story, with image and alignment checks. - Extend the service test to check saved images and missing images. ## Verification - Token gates and `git diff --check` pass. - The 33 existing chat setup and identity-link UI tests pass. - The OAuth installer service regression test passes. - Chromium rendered the Storybook Access story at desktop and mobile sizes. The avatar, name block, and Disconnect button centers all measured 307 CSS pixels on desktop. - UI typecheck passes. Full repository typecheck and build stop at the Rust runner because this workspace has no `cargo`. The initial parallel typecheck also exceeded the 4 GiB workspace limit. The full local test attempt was stopped as memory approached the 4 GiB limit; it has no complete verdict. CI passed the full build, typecheck, test, and E2E lanes on the initial commit. The previously reviewed commit passed 54 checks with two intentionally skipped Storybook checks. Master was merged on October 10 to resolve an import conflict; fresh CI is running for `24badb742d331c1b6ee3e90cbd06defefe5cd634`. Token gates and whitespace checks pass after conflict resolution. The single retry after CI runner shutdowns passed. Greptile gives this commit 5/5, with both review threads resolved. ### Screenshots The Storybook fixture shows an image, fallback initials, and a pending account. ![Desktop access rows](https://raw.githubusercontent.com/paperclipai/paperclip/fix/app-access-user-avatar/doc/screenshots/app-access-avatar/desktop.png) ![Mobile access rows](https://raw.githubusercontent.com/paperclipai/paperclip/fix/app-access-user-avatar/doc/screenshots/app-access-avatar/mobile.png) ## Risks Low risk. The API field is additive and needs no migration. The image uses the same avatar primitive as other user identities. Missing or failed images retain the initials fallback. Other chat providers share this access row. ## Model Used OpenAI Codex, GPT-6. Tool use and code execution. The runtime does not expose a more specific 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 - [ ] 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> canary/v2026.1013.0-canary.3	2026-10-12 23:54:01 -05:00
Devin FoleyandPaperclip	6c198d616e	fix(issues): preserve human handoffs from the active agent run (#16082 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Tasks have one owner, and the server records assignment changes. > - An agent can finish its work by handing the task to a human for review. > - The assignment route stops the active run before it saves that handoff. > - When the caller is that run, a slow workspace restore can exceed the stop timeout and prevent the assignment from saving. > - Recovery can then mark the task Blocked while its comment says the handoff succeeded. > - This pull request lets the authenticated legacy run save a human handoff and finish its turn normally. > - Other actors and transfers to executable agents keep the verified stop requirement. ## Linked Issues or Issue Description Refs #13730. Related: #13782, #14700, and #15094. What happened? An agent posted its review handoff, then sent `PATCH /api/issues/{id}` to assign the task to its human creator with status `in_review`. The route cancelled that same run before saving the assignment. Workspace restore took 66 seconds. The stop limit is 60 seconds. The assignment never committed. Recovery marked the task Blocked, and it stayed assigned to the agent. Expected behavior The authenticated active legacy run can hand its own task to a human and finish normally. The human assignment and requested review status must save without waiting for workspace restore. Native runs, board reassignment, agent API keys, and transfers to another agent still require a verified stop. Steps to reproduce 1. Run a legacy agent on its assigned task with a signed run token. 2. Send a task PATCH from that run with a human `assigneeUserId`, a null `assigneeAgentId`, and status `in_review`. 3. Make stopping the sandbox take more than 60 seconds. Before this fix, the handoff fails before the task update. With this fix, the update saves and the run finishes normally. Paperclip version or commit Reproduced in hosted execution. The patch is based on master at `56a0bf0d492`. Deployment mode Hosted authenticated server with a legacy agent in a remote sandbox. The same route serves local deployments. PR #13782 proposes a broader exemption for all self-handoffs. This focused change limits the exemption to human recipients and legacy runs. It checks the exact active run, agent, company, and task, and it retains the stop requirement before an executable successor can take ownership. PRs #14700 and #15094 address later wake and recovery behavior after a reassignment stop. ## What Changed - Skip the reassignment cancellation only for an authenticated legacy run handing its own task to a human. - Reject later mutations from the outgoing run against its human-owned task, both in route authorization and under the update transaction locks. - Keep assignment permission checks, goal control, and queued human response protection. - Add route regressions for slow stops, active-run lookup, actor and runtime boundaries, recipient types, permission denials, and follow-up edits, completion, and reassignment. - Update the real HTTP low-trust handoff test to prove the run stays alive, its late edit fails, and the human wake receipt remains invalidated. - Add Postgres tests for saved assignment, former-owner rejection, and review state after the outgoing run succeeds or fails. - Document the handoff rule and update the task feature and agent access maps. ## Verification - 328 relevant tests passed across the route, issue service, low-trust HTTP, and legacy recovery suites. The route suite passed all 160 tests, and all 13 low-trust HTTP tests passed after updating the obsolete cancellation expectation. - Removing the production guard makes both slow-shutdown handoff regressions fail with HTTP 500. - `pnpm -r typecheck` passed. - `pnpm build` passed. - `node scripts/check-maps.mjs` passed. - `git diff --check` passed. - All 54 current-head checks passed; 2 optional Storybook checks were skipped. The CI lanes cover the full Vitest suite, typecheck/build, Runner checks, and product E2E checks. - Apex reviewed `c68fbfb356c3d80eb7136babb49940709a3c3459` at 5/5 with no findings; both earlier review threads are resolved. - The complete test lanes passed in CI. The duplicate local full `pnpm test:run` was stopped after CI completed; it did not finish locally. All 328 focused local tests and full local typecheck/build passed. ## Risks - The outgoing legacy turn stays alive after the human takes ownership. Route and transactional ownership checks reject its later mutations of the human-owned task. Read and comment access follows normal policy. Goal control still runs before the handoff. - This exemption does not apply to native runs or another agent as recipient. Those paths still stop the old execution before assignment. - This fix prevents future failed handoffs. It does not infer or replay old assignment requests. - There is no schema change or API shape change. ## Model Used OpenAI GPT-6 through Codex, with reasoning, repository tools, and code execution. The session does not expose a more specific 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-12 20:34:28 -07:00
DottaandPaperclip	e168512f7b	perf(chat): stop polling failed run retries (#15871 ) Stop one-second scans of failed chat-run retries. Wake the existing retry queue after transaction commits and at saved retry or stale-claim deadlines. Preserve claim fences, authorization, recovery, and idempotent agent admission. Resolve conflicts with the current chat-service extraction by applying the retry signals and shared deadline predicate in the failed-run retry module. Verified with pnpm typecheck, pnpm build, all 1,328 chat and coordinator regression tests, and current-head CI. Greptile reviewed the final head at 5/5 with no unresolved threads. Co-Authored-By: Paperclip <noreply@paperclip.ing> canary/v2026.1013.0-canary.2	2026-10-12 19:49:47 -07:00
Devin Foley github-actions[bot]devinfoley Claude Fable 5.1	7d2bb5aaab	docs(release): stable notes for the 2026.1012.1-beta.0 soak (v2026.1015.0) (#16053 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release process promotes a soaked beta to stable. The stable GitHub Release body comes from `releases/beta/v<beta-version>.md` on `master` > - The `draft_stable_notes` job pushed a commit-log skeleton to this branch when `2026.1012.1-beta.0` published today (workflow run 38311557959) > - The skeleton is grouped commit subjects. It is not in release-notes voice and it does not tell a self-hoster what to do before an upgrade > - This pull request replaces the skeleton with curated notes. Each claim traces to a pull request in `v2026.1012.0..1b4c8038` > - The benefit is that the earliest stable promotion (v2026.1015.0) finds finished notes on `master` on time ## Linked Issues or Issue Description Issue type Missing content Where is the issue? `releases/beta/v2026.1012.1-beta.0.md` — the stable-notes file for the `2026.1012.1-beta.0` soak. It exists only on this machine-owned branch and only as the auto-generated skeleton. What's wrong? The stable promotion reads this file from `master` and publishes it as the GitHub Release body. Until this branch merges, the stable preflight has no notes to resolve. The skeleton lists raw commit subjects with nested PR summaries. It does not call out the three changes that need operator attention before the upgrade. Suggested fix Merge the curated notes so the notes invariant holds for the v2026.1015.0 promotion. Correct the `> Released:` date in a follow-up if the promotion date slips. ## What Changed - Replaced the skeleton in `releases/beta/v2026.1012.1-beta.0.md` with curated stable notes for v2026.1015.0 in the same layout as `releases/beta/v2026.1006.0-beta.0.md`: overview, Breaking Changes, Highlights, Fixes, Improvements, Upgrade Guide, Contributors - Breaking Changes lists the expanded Operator role preset (#15377), GitHub review bots behind a new default-off experimental setting (#15416), and budget policies that hold on unpriced usage by default (#14997) - Upgrade Guide enumerates migrations `0306` through `0333` with one-phrase effects, the three new environment variables with defaults, the three new default-off experimental settings, the new agent identity key variables for custom adapters, and the private-task API behavior - Release and CI internals, smoke specs, canary tooling, Paperclip Cloud work, heartbeat refactors, dependency bumps, and test-only changes are left out. Features already described in the v2026.1012.0 notes are not repeated ## Verification - Beta publish is complete: npm dist-tag `beta` is `2026.1012.1-beta.0`, tag `beta/v2026.1012.1-beta.0` points at `1b4c803816e82b0265c8422e1a804327a7ed8c54`, and the `publish_beta`, `smoke_beta`, and `draft_stable_notes` jobs in run 38311557959 all succeeded - `git rev-list --count v2026.1012.0..1b4c803816e82b0265c8422e1a804327a7ed8c54` returns 200, which matches the overview and Contributors section - `git shortlog -sn --no-merges` over the same range shows 6 human authors after the two bot accounts are excluded. The two external handles were read from the GitHub commit authors, not guessed from names - `./scripts/release.sh stable --date 2026-10-15 --print-version` returns `2026.1015.0` - Every `#NNNN` link in the file resolves to a pull request inside the range. Migration numbers, setting keys, env var names, and defaults were checked in the code on the source commit, not in commit subjects - The file contains no internal ticket ids or instance-local links - The compare view for this branch shows one added file and no source changes ## Risks - Low risk: a single markdown file, no source changes. If the promotion date slips past 2026-10-15, the `> Released:` line and H1 need a one-line update before the stable dispatch. The beta-keyed filename makes that re-date harmless ## Model Used - Claude (Anthropic), model ID `claude-fable-5-1` (Claude Fable 5.1), extended thinking enabled, tool use via Claude Code ## 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-10-12 19:43:04 -07:00
Devin Foley Paperclip Dotta	56a0bf0d49	Support test Cloud connector identities (#16033 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its Cloud connector uses an environment-bound identity to call a hosted broker. > - The identity parser and enrollment flow accept development, staging, and production. > - A separate test broker needs its own environment identity. > - This pull request accepts test identities and maps the test broker to that environment. > - Known hosted brokers still reject identities from other environments. ## Linked Issues or Issue Description What existing behavior does this improve? Cloud connector configuration and self-host enrollment. Current behavior The app rejects an identity with environment `test`. Self-host enrollment infers development for the test broker. Proposed behavior Accept `test` identities at `https://test.paperclip.app`. Infer test during self-host enrollment. Reject development, staging, and production identities at that broker. Continue to reject test identities at the production and staging brokers. Reason and benefit Branch testing needs a separate broker so test identities and requests stay in their selected environment. The existing identity, enrollment, and signature flow can provide that isolation with a new allowed environment value. Breaking changes Existing environment values and broker checks keep their current behavior. Older app versions cannot use test connector identities. ## What Changed - Add `test` to managed and self-hosted connector environment types and validation, and to the board API enrollment status type. - Infer test from its hosted broker and enforce the matching environment. - Test enrollment persistence, signed request environment/audience claims, and broker mismatch rejection. - Document test broker configuration in the development guide. ## Verification - Connector, enrollment, and board API-client suites passed: 63 tests across three files. Board UI typecheck and token gates passed after synchronizing its enrollment response type. - `pnpm -r typecheck` and `pnpm build` passed, including after rebasing onto current master. - `pnpm test:run` completed its general server stage: 17,867 passed, 105 skipped, and 9 failed across 5 files. The runner stops at that failing stage, so it did not run subsequent workspace/serialized stages locally. All nine failures also reproduce on the unchanged base commit in a separate checkout. Five skill-related cases resolve an unrelated ancestor skills directory; two workspace cases accept a remote main branch that their fixture expects to be absent; two permission-cleanup cases return macOS `ENOTEMPTY` instead of the expected permission error. - Current-head GitHub CI passed, including full general and serialized test suites, typecheck, build, runner checks, and browser e2e. Greptile is 5/5 with no unresolved comments. - `git diff --check` and Gitleaks passed. ## Risks The new environment value is additive. The test broker must support test identities before use. This change preserves existing signature handling, managed identity overrides, and rejection of mismatched identities at known hosted brokers. A local full-suite pass is not claimed; the nine failures above also occur without this change. ## Model Used OpenAI Codex, GPT-6, with reasoning and tool 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 - [ ] 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> Co-authored-by: Dotta <34892728+cryppadotta@users.noreply.github.com>	2026-10-12 19:32:33 -07:00
Devin Foley Paperclip Amy	83e13db8fa	fix(inbox): keep automatic recovery cleanup out of personal participation (#16063 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The personal inbox uses issue activity to identify a person's participation. > - Issue reads can cancel stale recovery actions and record that cleanup as the reader's action. > - This adds unrelated tasks to the inbox and refreshes their activity timestamps. > - A workspace owner hold can also alternate between creation and cancellation after a task finishes. > - This pull request corrects cleanup attribution, excludes historical read cleanup, and retains one exact owner hold. > - Agents can read authorized issue activity to diagnose the same problem themselves. ## Linked Issues or Issue Description Refs #15742 excludes logs by the execution-recovery actor from activity timestamps. This PR covers reader-attributed stale recovery cleanup, personal inbox participation, exact workspace owner holds, and sandbox issue activity access. I searched open issues and PRs for recovery inbox and activity bridge fixes. I found no duplicate for this defect. What happened? Loading issue lists cancels stale recovery actions under the reader's identity. The personal inbox treats those rows as user participation. One completed issue had hundreds of such rows and no edits or comments by the affected reader. A retained native workspace owner repeatedly creates a verification action that read projections then cancel. Sandbox agents cannot inspect the issue activity because the reverse bridge rejects the route. Expected behavior Automatic cleanup belongs to the system and does not add an issue to a reader's inbox. Historical cleanup rows remain auditable but do not count as participation or recent activity. An unresolved physical workspace owner keeps one stable verification action. Agents can inspect activity only for issues their identity may read. Steps to reproduce 1. Finish a task whose native run retains an unverifiable workspace owner receipt. 2. Repeat workspace recovery checks and GET requests for issue detail, compact lists, and recovery actions. 3. Observe new recovery action IDs and reader-attributed cancellations in the activity history. 4. Query the personal inbox for that reader and observe the unrelated task. 5. From a sandbox agent, request GET /api/issues/:id/activity and observe Route not allowed. Paperclip version or commit Observed at `f5346c05b9`. Regression tests use current master behavior. Deployment mode Authenticated hosted instance with native and legacy sandbox agents. The inbox defect is independent of the adapter. ## What Changed - Attribute automatic stale recovery cleanup to the recovery system actor. - Exclude exact historical read cleanup rows from personal inbox membership, unread counts, and both activity timestamp queries. Keep all audit rows and explicit user recovery decisions. - Retain owner verification holds only while the exact company, run, issue, and owner fingerprint still match. Apply the same rule to reads and background recovery. - Make repeated checks for the same owner hold leave its identity, attempts, and timestamps unchanged. Keep physical takeover blocked. - Allow GET issue activity through the sandbox bridge. Keep the existing company and issue-read authorization and reject broader audit routes. - Add regressions and update the runtime API and recovery documentation. Refresh generated source references for the documentation edits. Update the paired activity, inbox, and recovery maps. ## Verification - Focused Vitest verification: 315 tests pass across five files. The updated terminal owner hold regression also passes. The files cover issue service, recovery routes, activity authorization, sandbox callback bridge, and native workspace finalization. - `pnpm -r typecheck` and `pnpm build` pass locally. The full general and serialized unit test matrix passes in CI on the latest commit. The duplicate local `pnpm test:run` was stopped after about 30 minutes once that full CI coverage passed; it did not report a local full-suite pass. - `node scripts/check-maps.mjs` passes for all paired areas and capability IDs. - Apex is 5/5 on commit `44c3787888`. Its access map finding is fixed and resolved. All CI checks are green on this commit. - The new regression repeats reads and background sweeps for done and cancelled tasks. It checks one unchanged hold, zero physical copyback, zero personal inbox participation, and system cleanup after the exact receipt is cleared. - Historical cleanup tests preserve explicit recovery decisions, nullable metadata, unread counts, and the original audit rows. - Authorization tests permit an authorized agent and reject cross-company or issue-boundary reads. Bridge tests reject write methods, extra path segments, and company-wide audit routes. ## Risks Existing inbox items can disappear if their only participation evidence was automatic read cleanup. No data migration or audit deletion is needed. An unresolved workspace owner remains visible after task completion; this preserves the physical writer fence. A stale or cleared owner does not retain the hold. Issue activity access expands only the sandbox transport allowlist and still uses existing controller authorization. ## Model Used OpenAI GPT-6 through Codex, with reasoning, repository inspection, code editing, shell execution, and test tools. The session identifies the model family as GPT-6. A more specific runtime 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 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> Co-authored-by: Amy (Opus) <noreply@anthropic.com> canary/v2026.1013.0-canary.1	2026-10-12 19:25:15 -07:00
DottaandPaperclip	f329b24ee1	feat: give tasks durable project-optional workspaces (#15749 ) Give tasks durable company-scoped workspace bindings independent of project assignment, channel defaults and authorized repository preparation. Reuse verified input seeds and sparse output recovery while preserving trust, privacy and controller provisioning boundaries. Full CI and E2E, Superagent, legacy checks and Greptile Apex 5/5 passed on reviewed head `753680b61c`. All review findings are resolved; the PR records focused verification and historical acceptance limits. Co-Authored-By: Paperclip <noreply@paperclip.ing> canary/v2026.1013.0-canary.0	2026-10-12 20:45:18 -05:00
Devin Foley Claude Opus 5.5 Dotta	4b958ecbd8	fix(server): keep classified provider quota runs out of Sentry (#16029 ) A run that stops because the user's provider account hit its usage limit is an expected wait, not a Paperclip defect. The adapter already classifies it (errorCode and resultJson.errorFamily are both provider_quota) and recovery schedules a retry at the reset time. Skip the Sentry report only when both adapter-owned fields agree, the run status is failed, no signal stopped it, and the failure did not happen during setup. Timeouts, cancellations, signals, other codes and missing or mismatched families still report. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: Dotta <cryppadotta@users.noreply.github.com> canary/v2026.1012.1-canary.3	2026-10-12 15:59:27 -07:00
DottaandPaperclip	64bd6e9e07	refactor(chat): extract delivery, reaction, and setup boundaries (#16024 ) ## Thinking Path > - Paperclip manages AI agents and their work. > - Chat channels connect that work to provider conversations. > - One shared service contains callback, delivery, reaction, and setup logic. > - These responsibilities have distinct contracts and existing public-path tests. > - This PR moves ten cohesive responsibilities into focused modules. > - The service retains shared runtime ownership and scheduling. > - Provider behavior is easier to locate and review. ## Linked Issues or Issue Description Refs #15995, #16026, #16027, #16030, #16031, #16035, #16037, #16038, #16041, #16043. This PR consolidates the reviewed extraction stack. The plan is `doc/plans/2026-10-12-chat-channel-delivery-boundaries-refactor.md`. ## What Changed - Move Slack callback verification into the Slack folder. - Move Discord Gateway events and root-thread admission/recovery into the Discord folder. - Extract durable receipt reactions and inbound reaction admission/replay. - Extract inbound attachment ingestion and outbound integrity-checked hydration. Preserve the public hydration export. - Extract durable provider effects. Keep Telegram callback notices in the Telegram folder. - Extract conversation/activity reads and setup qualification. Keep Slack and Teams projections in their channel folders. - Preserve the merged managed Slack setup behavior, shared workers, credential leases, and transaction boundaries. - Reduce `chat-channels.ts` from 26,493 lines / 1,048,769 bytes to 21,460 lines / 862,284 bytes. This removes 5,033 lines from the service. ## Verification - Each extraction passed its selected existing tests before and after through public service paths. - On updated master, all 55 selected Slack cases passed before extraction. All 194 selected chat/managed-Slack cases passed on the final stack tip. - `pnpm -r typecheck`, `pnpm build`, module-boundary checks, and whitespace checks passed on that tip. - The normalized syntax audit verifies 69 moved declarations and all retained statements, including their relative order, against updated master. - The eight earlier stack merges retain the exact validated repository tree. The combined root equals the validated tip merged with current master. All chat-channel files remain byte-identical to the validated tip. Current combined-root CI and review are pending. - Full local verification remains unverified. The unchanged `workspace-git-snapshot-streaming.test.ts:56` stress test timed out at 300,000 ms in a clean run and again in isolation. The full run was stopped after the reproduced failure. No timeout or assertion was weakened. - These checks use assembled services, real local databases, and provider fixtures. They do not prove live third-party execution. Reviewers can run the public-path suites: ```sh pnpm exec vitest run server/src/__tests__/chat-channels.integration.test.ts server/src/services/chat-outbound-attachment-hydration.test.ts server/src/__tests__/slack-development-manager.test.ts ``` ## Risks - Factory wiring must preserve live values, shared state, and initialization order. Identity-link construction retains deferred access to the provider-effects callback. - Credential fences, authorization transactions, and delivery settlement must keep their original ordering. Syntax parity and public-path integration cases cover these boundaries. - Full local verification has the recorded Git-streaming timeout. The combined PR must pass master’s required CI before merging into master. ## Model Used OpenAI Codex, GPT-6 family, with reasoning and repository tools. The exact runtime model ID and context-window size are not exposed in this session. No separate agent was 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 - [ ] 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> canary/v2026.1012.1-canary.2	2026-10-12 22:46:25 +00:00
Devin FoleyandPaperclip	9b1b905e01	fix(heartbeat): answer an unsettled adapter Stop with a 409 instead of a 500 (#16032 ) An owned adapter Stop that is still settling when the 60s request wait expires now returns 409 adapter_stop_pending instead of escaping as an HTTP 500. Stop proof, lease and restore ownership are unchanged. Sentry is notified only when the same execution is still unsettled ten minutes after the Stop request (measured from stopRequestedAt), so real Stop hangs stay visible and slow workspace sync-back no longer pages. Co-Authored-By: Paperclip <Paperclip-Paperclip@users.noreply.github.com>	2026-10-12 15:44:47 -07:00
DottaandPaperclip	88bf4c6c1d	refactor(storybook): organize folders and navigation by feature map (#16049 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The feature map describes product areas and verification entry points. > - Storybook has 223 story suites that show production components, proposals, and retained history. > - The parent PR maps those suites to features, but their folders and sidebar still use unrelated groups. > - This pull request puts the existing suites under feature folders and uses the feature map's names and order in the sidebar. > - Explicit meta IDs preserve existing story links while the titles change. > - Contributors can find stories through the same product structure without losing examples. ## Linked Issues or Issue Description Refs #16046. This is the requested follow-up. Parent #16046 is merged. This PR now targets master, with its single follow-up commit rebased onto the parent squash merge. The Storybook implementation is unchanged by that rebase. Related open Storybook PRs were checked; this change organizes existing suites and adds no product capability. ## What Changed - Move all 223 story files into folders named for their primary feature area. Keep useful scenario groups below the feature's sidebar label. - Order the sidebar by the eight feature-map sections. Put Overview first and shared Foundations last. Leave areas with no stories out of the sidebar. - Move 19 support files into `ui/storybook/support/` and update relative imports and active documentation. - Preserve all 2,210 story IDs and the single docs ID through explicit CSF meta IDs. Keep all entry names and story exports. - Record stable IDs and sidebar titles in the downstream catalog. Validate feature folders, title prefixes, and IDs. Update the maintenance skill and review evidence. ## Verification - Storybook build passed. Built index comparison against parent `75bd3c977cd828d5222823850339e8204f40eb47` found the same 2,211 entries, IDs, and names. - UI typecheck passed (`ui/node_modules/.bin/tsc -b` from `ui`, invoked as `./node_modules/.bin/tsc -b`). - UI Vitest project: 728 files and 8,176 tests passed. - Catalog checker and its nine tests passed. Feature-map checks, token gates, and the maintenance-skill validator passed. - Chromium: nine existing play cases and one render case reached `storyFinished: success` with no page exceptions. The guide rendered, sidebar sections followed map order, and a search for `steering/queue` opened its preserved story link. - Source comparison found only meta title/ID changes, rebased relative references, and updated fixture path text in story files. - To inspect: build Storybook, start `node scripts/serve-storybook-static.mjs --port 6136`, and open the Overview guide. Expand feature folders and use existing story links. - The complete repository suite was not repeated for this organization change. The parent records a backend timeout that passed in isolation, without a complete broad-suite pass. Visual comparisons remain blocked by the unpublished empty baseline. The separate fixture-server story was not run. ## Risks - Open branches that add stories under old paths will need to choose a feature folder and update the catalog. Cross-feature suites have one primary home and retain related capability references. - Sidebar paths change; story and docs IDs remain stable. Automated references to source paths may need the new location. - This is one requested follow-up with 258 changed files, mostly moves. It exceeds the usual review-size guideline because splitting it would leave the sidebar and folder convention partly migrated. - Browser verification samples ten stories, not all 2,210. Existing production/prototype classifications and review gaps remain unchanged. - Required CI gates and a 5/5 review passed on the original head. Fresh checks and review are running for the rebased head. Catalog validation and all nine checker tests passed after rebase; UI, map, skill, and checker contents are identical to the original reviewed head. ## Model Used - OpenAI Codex, GPT-6. The exact runtime model ID and context-window size are not exposed in this session. Used reasoning, repository inspection, code execution, and local browser automation. ## 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>	2026-10-12 22:29:22 +00:00
DottaandPaperclip	dabb8c5daf	test: remove repeated setup and strengthen regression proof (#16022 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its tests protect company boundaries, approvals, durable tasks, credentials and the board UI. > - Several owner suites repeat large database fixtures and render frames. > - Some tests repeat stronger proof or pass when the behavior they describe is broken. > - This pull request shares exact setup, removes proven duplicate cases and repairs weak observations. > - It preserves distinct security, lifecycle, concurrency and user-facing contracts. > - The benefit is 5,027 fewer test lines and stronger regression checks. ## Linked Issues or Issue Description Refs #15978. This continues the merged test-audit cleanup in [PR #15978](https://github.com/paperclipai/paperclip/pull/15978), which removed 11,976 test/support lines. The savings in this pull request are additional. Related open work: [PR #13460](https://github.com/paperclipai/paperclip/pull/13460) changes legacy OAuth parent/version lock ordering. This pull request retains those production paths and the existing lock-order test. Its secrets changes compact fixtures and repair the two AWS wrapper exclusion observations. Scoped title searches found no open duplicate audit or fixture-consolidation PR and no matching audit issue. The problem is described here using the enhancement template. What existing behavior does this improve? The maintenance and regression value of the existing server, UI, CLI, shared and wiki-plugin test suites. Subsystem affected Cross-cutting test code. Two UI modules also lose unused test inspection exports. Current behavior Owner tests repeat database rows, service inputs, HTTP setup and render frames. Some cases repeat stronger assertions. Two AWS lock tests record only cleanup events, so an AWS provider write can happen inside the held lock without failing those observations. Several other negative tests accept or do not observe the wrong result. Worktree fixtures also use a temporary path alias that conflicts with the existing canonical-path checks on macOS. Proposed behavior Use small local helpers that preserve exact inputs, fresh allocations, callbacks, query order and await positions. Remove only cases with named stronger keepers. Tighten negative assertions and observe actual AWS provider entry while a confirmed lock holder remains parked. Resolve temporary fixture roots to their canonical paths. Reason and benefit Remove 5,027 net test lines and 15 redundant registered executions. Remove 11 lines of unused UI inspection exports. Keep every distinct company, actor, approval, credential, persistence, stale-write and concurrency contract. No wall-time speedup is claimed for setup compaction. Breaking changes None for application behavior, APIs or stored data. The removed exports expose private UI test state and have no remaining callers. ## What Changed - Consolidate repeated runtime, workspace, portability, route, tool-access, policy, gateway and state-service fixtures. - Share repeated UI render frames and CLI/wiki-plugin setup while retaining the original actions and expected results. - Remove 15 repeated case executions only where the audit records an exact stronger keeper. - Repair weak HTTP/UI negative assertions and two AWS account-home lock observations. Keep the existing durable results and cleanup behavior. - Remove the unused `__inflightGetCount` and `__secondTickInternals` inspection exports. Keep observable request coalescing and ticker lifecycle checks. - Canonicalize temporary worktree fixture paths without weakening production path checks. - Record the owner decisions, savings, independent preservation reviews and validation in [the dated audit report](https://github.com/paperclipai/paperclip/blob/58c5c4aa241c85f4665a3159c192888bbb2a5cfa/doc/plans/2026-10-12-test-audit-rounds.md) and [the compact control evidence](https://github.com/paperclipai/paperclip/blob/58c5c4aa241c85f4665a3159c192888bbb2a5cfa/doc/plans/2026-10-12-test-audit-controls.json). ## Verification - Complete owner and retained-sibling baselines passed before each audit cutover. Independent reviewers checked the full original tests, actual helper bodies, exact inputs, receipt provenance, async order, fresh allocations and case registrations. - All 14 UI/route/wiki mutations failed at their intended assertions: ten UI/API/ticker controls, one route control and three wiki persistence/receipt controls. Each mutated production source was restored to its exact original bytes. - Both old AWS lock tests passed with their respective AWS-only lock bypass. Both repaired tests failed at the intended assertions with the same bypasses. These give 16 intended failures and two passing weak controls across 18 executions. Each source was restored exactly. - Final complete state-owner/sibling run: 329/329 passed at code revision `64370831ebe191e5ce092f85f79b6fb661df7e16`. - Final `pnpm -r typecheck`, `pnpm check:token-gates` and `pnpm build`: passed at the same code revision. - Delivery head `58c5c4aa241c85f4665a3159c192888bbb2a5cfa` includes the evidence commit and master `4b766b872993045a2e787404f0475503683e5ded`. All 27 audited test files and both application files match the locally verified code revision byte-for-byte. Current-head CI validates the integrated branch, including the incoming master changes. - All eight production-owner SHA guards for the 16 deliberate failing mutation controls still match the integrated delivery checkout. The mutation receipts therefore apply to those current owners. - Full default `pnpm test:run`: failed with exit 1 at frozen code revision `64370831ebe191e5ce092f85f79b6fb661df7e16`; HEAD and tracked source bytes remained unchanged. The first general-server group reported 878 passing files, four failing files and six skipped files; 17,846 passing cases, 24 failing cases and 105 skipped cases. Later groups did not run. Failures were `http-log-redaction` (socket hangup), `public-mcp` (initial 15-second timeout followed by hosted token “Refresh before subscribing” failures), `remove-test-home` (macOS `ENOTEMPTY` where permission errors were expected, plus cleanup failure), and `workspace-git-snapshot-streaming` (300-second timeout). All four failing test files and the relevant cleanup/MCP production owners are unchanged by this audit. Full local success is not claimed. - Focused complete-owner diagnosis at the same frozen revision: 149/152 passed, three failed, zero skipped. `public-mcp` passed 82/82 and `http-log-redaction` passed 66/66 unchanged. The two `remove-test-home` cases reproduced macOS `ENOTEMPTY` against an expected `EACCES`/`EPERM` contract; the 32 MiB workspace snapshot case reproduced its existing 300,000 ms timeout. HEAD and tracked files stayed clean. Exact blob comparison confirmed all four test files and the relevant cleanup/MCP owners match both inspected master `4b766b872993045a2e787404f0475503683e5ded` and the frozen local revision. The three remaining local failures are unresolved; no timeout, retry or assertion was weakened. - Current-head CI: [workflow 38299262149](https://github.com/paperclipai/paperclip/actions/runs/38299262149) has passed runner selection and created all downstream test/typecheck/build gates; those gates are queued, with no failures reported. Greptile completed successfully at `58c5c4aa241c85f4665a3159c192888bbb2a5cfa` with [5/5 and zero comments](https://github.com/paperclipai/paperclip/pull/16022#issuecomment-6131457592). All review threads are resolved or absent. This pull request will remain open after verification. Reviewers can reproduce the required workspace checks: ```sh pnpm -r typecheck pnpm check:token-gates pnpm test:run pnpm build ``` Browser suites were not run. Their sources and user journeys are unchanged by this audit. ## Risks - A fixture helper can hide a specialized input or change object freshness. Full-program expansion checks and independent reviews preserve the exact old inputs and execution order. - Removing duplicate proof can remove a distinct contract by mistake. The audit records the keeper for each deletion; all distinct security and lifecycle cases remain. - Concurrency checks can miss progress during a fixed delay. The AWS repairs record actual provider entry, confirm holder entry, use measured entry windows, require exact final event order and drain both operations in `finally`. - The full local default run failed. Focused diagnosis reproduced two macOS cleanup failures and one existing snapshot timeout in unchanged owners; these remain unresolved. Current-head CI is pending. No test deadline, retry policy, skip or CI shard was weakened to obtain a pass. > 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 with GPT-6, reasoning, repository inspection, code execution and delegated audit/review. The runtime does not expose the exact served model identifier or context-window size; those values are unavailable and are not inferred from the model catalog. ## 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 - [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-12 22:23:11 +00:00
DottaandPaperclip	9e721264e9	feat: maintain Storybook through a downstream feature catalog (#16046 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Storybook supports review of its production UI and proposed designs. > - Its 223 story files have no consistent link to product capabilities or record of component and mock provenance. > - Old compositions can drift while they still look like current product examples. > - This pull request adds two maintenance skills and a catalog that consumes the existing feature map. > - The first audit preserves all stories and fixes proven fixture drift. > - Contributors can now find examples by feature and see what still needs review. ## Linked Issues or Issue Description What existing behavior does this improve? Storybook maintenance, feature discovery, and the accuracy of isolated UI examples. Current behavior Stories are already centralized under `ui/storybook/`, but their sidebar has 51 top-level groups. Production components, local prototypes, and historical designs are not consistently distinguished. The old guide uses manual coverage claims. GitHub searches found no duplicate feature-map catalog change. Proposed behavior Keep existing story locations and IDs. Add a downstream catalog keyed to stable feature capabilities. Record product status, rendered subject, data boundary, and declared review dependencies separately. Use dedicated maintenance and review skills to reconcile drift and report evidence. Reason and benefit The catalog makes existing examples reusable without treating mock behavior or old designs as production acceptance. The feature map remains independent of Storybook. ## What Changed - Add `maintain-storybook` and `review-storybook` skills with contributor guidance. - Inventory all 223 story files. Generate a feature index and provide searchable navigation in the existing Overview story. Track direct subjects through relative imports and local wrappers, including the primitives demonstrated by foundation suites. - Add a checker for inventory, capability references, duplicate IDs, and declared-source drift, with eight regression tests. The parser test covers real nested CSF files, export filters, explicit IDs, and play counts. - Preserve historical designs and classify mixed wrappers. Record the initial audit and remaining parity work. - Align the question-dismiss/send fixture with production behavior. Add dismissal and confirmation-reopen regressions and repair the editor selector. - Exclude three exported fast-response fixtures from story discovery and add the missing render-time callback spy. ## Verification - Passed: `node scripts/storybook-catalog.mjs`, `node --test scripts/storybook-catalog.test.mjs` (8 tests), and `node scripts/check-maps.mjs`. - Passed: validators for both new skills, `pnpm check:token-gates`, `pnpm -r typecheck`, and `pnpm build`. - Passed: final Storybook build; nine selected browser `play` cases; three fast-response render cases; feature-guide search/link navigation; question-fixture reset on reload. - Built-index comparison preserved all 2,208 original story IDs and added only two new regression cases. - Passed: `pnpm exec vitest run --project @paperclipai/ui` (728 files, 8,176 tests). - The full `pnpm test:run` has reported a 15-second timeout in the untouched backend case `connects advertised Workspace gmail.read without mutating definitions in authenticated`. The exact test passed standalone without changing code, expectations, or timeouts. The remaining broad run was stopped after this failure. The full suite is not verified. - Visual comparison is blocked by the existing empty baseline manifest. The managed-accounts API/DB fixture was not started. See `maps/storybook-map/REVIEW.md` for exact scope. ## Risks - This is an initial inventory and targeted audit. 188 suites still require deeper state and fixture parity review. - Review hashes cover declared dependencies. They do not follow all transitive production imports or prove semantic correctness. - The catalog requires upkeep when stories, mapped recipes, or declared subjects change. Shared mocks still need feature-by-feature contract review. - No production application source, database schema, or upstream feature-map contract changes. ## Model Used OpenAI GPT-6 via Codex. Used reasoning, shell tools, file editing, and Chromium browser verification. The exact runtime 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 - [ ] 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>	2026-10-12 17:20:00 -05:00
DottaandPaperclip	f5346c05b9	ci: route PR admission through reserved AWS capacity (#16042 ) ## Thinking Path > - Paperclip uses CI to verify changes before release. > - Trusted PR tests can run on isolated AWS workers. > - Their runner-selection job currently waits for GitHub-hosted capacity. > - A large hosted test queue therefore blocks admission to AWS. > - A dedicated routing workflow lets us reserve capacity for metadata validation. > - This PR moves the routing job to reserved AWS capacity after the bootstrap workflow and pool are available. ## Linked Issues or Issue Description Issue type CI reliability enhancement. Where is the issue? The Select trusted runner job in PR CI. What's wrong? The routing job competes with a large hosted test queue. Its sampled median wait was about 20 minutes. AWS tests cannot begin before this job finishes. Suggested fix Add a protected reusable routing workflow. Deploy its dedicated AWS pool, then switch the PR caller in a follow-up PR. No overlapping open PR or issue was found. ## What Changed - Call ci-routing.yml on protected master from pr-trusted.yml. - Check the canonical repository and approved PR author/sender before allocating reserved AWS metadata capacity. Unapproved PRs continue to use hosted routing. - Permit approved manual routing canaries on protected master. - Use a validated roster snapshot for placement. Invalid JSON, missing settings, stale snapshots, and unapproved identities select hosted routing without a placement-time JSON parse. - Preserve the full in-job identity, rerun actor, repository, head, merge, and stack checks. - Update stack-scope and placement regression tests and document the pool and rollback. ## Verification - The routing scripts and placement expression tests passed (44 tests), routing-plus-shard tests passed (56 tests), and the existing .github/scripts suite passed (381 tests). - Existing routing allow/deny scenarios passed with the extracted script (16 cases). - actionlint passed with the dedicated custom runner label declared in its local configuration. - git diff --check passed. - Full pnpm typecheck/test/build cannot run in this worktree because dependencies are not installed. The change is limited to workflow YAML and Node tests. - The dedicated pool is deployed with two warm On-Demand workers and a four-worker ceiling. The routing qualification passed: it started about five seconds after workflow creation, selected AWS, and finished while the hosted gate in the same PR remained queued. - Bootstrap https://github.com/paperclipai/paperclip/pull/16039 is merged. The deployed group now authorizes only ci-routing.yml on protected master, and its master canary passed. ## Risks - The maintainer explicitly approved a queued-CI admin bypass after current-head Greptile 5/5 and focused verification. - Activation requires the deployed routing Fleet and its group to authorize the routing workflow on protected master. Keep the bootstrap dependency explicit. - The group must authorize only ci-routing.yml on protected master and canonical repository ID 1170821064. - The routing workflow runs no checkout or PR code and has read-only permissions. The test admission checks are unchanged. ## Model Used - OpenAI GPT-6 via Codex, with reasoning, shell tools, and file editing. The exact runtime 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 (focused routing and workflow tests; full pnpm commands are blocked by missing worktree dependencies) - [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] Required CI status checked; the maintainer explicitly approved admin bypass for queued CI after clean current-head review and focused verification - [x] Greptile is 5/5 on `993fbe695a` with no open findings or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> canary/v2026.1012.1-canary.1	2026-10-12 16:47:57 -05:00
Devin Foley devinfoley Claude Fable 5.1	2b8da4ab64	docs(release): canonicalize v2026.1012.0 release notes (#16045 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release process keeps one curated notes file for each release in `releases/` > - Beta notes live in `releases/beta/` until the beta becomes a stable release > - v2026.1012.0 was published from beta 2026.1006.0-beta.0 on 2026-10-12 and its notes file still has the beta path on master > - The release workflow did not push its usual canonicalize branch because the notes came from the source tree of the release candidate > - This pull request renames the beta notes file to the stable path > - The benefit is that the stable notes link `releases/v2026.1012.0.md` resolves on master and the beta path does not stay as a duplicate ## Linked Issues or Issue Description Describe the problem The stable release v2026.1012.0 is published. The GitHub Release body is the notes file that PR #16000 merged. On master, that file is still at `releases/beta/v2026.1006.0-beta.0.md`. The stable path `releases/v2026.1012.0.md` does not exist on master. Links to the stable path return 404. Expected behavior The notes for v2026.1012.0 are at `releases/v2026.1012.0.md` on master. The beta path is removed. The content is identical to the GitHub Release body. Additional context Related: #16000 (pre-publish notes fix) and #15388 (curated beta notes). ## What Changed - Rename `releases/beta/v2026.1006.0-beta.0.md` to `releases/v2026.1012.0.md`. - This is a pure rename. The file content does not change. Git reports `R100`. ## Verification - Run `git diff -M --name-status master...release-notes/v2026.1012.0-canonicalize`. The output is one line: `R100 releases/beta/v2026.1006.0-beta.0.md releases/v2026.1012.0.md`. - Compare the file with the GitHub Release body at https://github.com/paperclipai/paperclip/releases/tag/v2026.1012.0. The content is the same. The git blob is `e7503b64aa5bcb74b2da6bb05a7da2554919e0ec` on both master and this branch. - The git tag `v2026.1012.0` points at the release candidate commit `bba6a45f0d364cfd962ac59b3bdf2426a8222adb`. That commit already has the same file at `releases/v2026.1012.0.md` with the same blob. ## Risks - Low risk. This is a documentation rename with no content change. No code or config changes. ## Model Used - Claude (Anthropic), model ID `claude-fable-5-1`, used through Claude Code with tool use and extended reasoning. The rename was done with `git mv`. No AI-generated content is in the file. ## 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> canary/v2026.1012.1-canary.0	2026-10-12 14:17:41 -07:00
DottaandPaperclip	8e7b5db822	ci: add protected routing workflow for reserved AWS capacity (#16039 ) ## Thinking Path > - Paperclip uses CI to verify changes before release. > - Trusted PR tests can run on isolated AWS workers. > - Their runner-selection job currently waits for GitHub-hosted capacity. > - A large hosted test queue therefore blocks admission to AWS. > - A dedicated routing workflow lets us reserve capacity for metadata validation. > - This PR adds that workflow without changing the active PR caller. ## Linked Issues or Issue Description Issue type CI reliability enhancement. Where is the issue? The Select trusted runner job in PR CI. What's wrong? The routing job competes with a large hosted test queue. Its sampled median wait was about 20 minutes. AWS tests cannot begin before this job finishes. Suggested fix Add a protected reusable routing workflow. Deploy its dedicated AWS pool, then switch the PR caller in a follow-up PR. No overlapping open PR or issue was found. ## What Changed - Add ci-routing.yml with the existing author, sender, rerun actor, repository, head, merge, and stack checks. - Target the dedicated paperclip-ci-routing-x64 Fleet. - Export runner and full_ci decisions to reusable workflow callers. - Add tests for metadata-only execution, reserved placement, and output forwarding. - Keep the active PR caller unchanged until the pool is deployed. ## Verification - The routing tests passed (30 tests), including 20 executed runner-selection cases and 8 executed stack-scope cases. - Existing routing allow/deny scenarios also passed with the extracted script (16 cases). - A live qualification job selected AWS and passed on the reserved routing pool in https://github.com/paperclipai/paperclip/actions/runs/38308312153/job/115007621128 while the hosted gate remained queued. - actionlint passed with the dedicated custom runner label declared in its local configuration. - git diff --check passed. - Full pnpm typecheck/test/build cannot run in this worktree because dependencies are not installed. The change is limited to workflow YAML and Node tests. - After merge, configure the restricted runner group, deploy the pool, and dispatch ci-routing.yml on master. The unused workflow does not affect current PR placement. ## Risks - The maintainer explicitly approved merging this rollout after current-head Greptile 5/5 and focused verification, while the hosted CI checks remain queued. - The dedicated Fleet must exist before the workflow can receive a runner. This PR introduces the workflow without switching active PR CI. - The group must authorize only ci-routing.yml on protected master and canonical repository ID 1170821064. - The routing workflow runs no checkout or PR code and has read-only permissions. The test admission checks are unchanged. ## Model Used - OpenAI GPT-6 via Codex, with reasoning, shell tools, and file editing. The exact runtime 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 (focused routing and workflow tests; full pnpm commands are blocked by missing worktree dependencies) - [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] Required CI was checked; the maintainer explicitly approved an admin bypass for queued checks after clean review - [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-12 16:14:35 -05:00
DottaandPaperclip	e364b92c82	docs: add PR rules for file size and code comments (#16036 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Contributors use CONTRIBUTING.md to prepare pull requests. > - The guide is missing two code submission rules. > - Contributors need to see these rules before they submit changes. > - This pull request adds the file size and code comment rules to the requirements for all PRs. > - The benefit is a clear statement of the requested contribution policy. ## Linked Issues or Issue Description Issue type Missing documentation. Where is the issue? CONTRIBUTING.md, PR Requirements (all PRs). What's wrong? The guide does not state the requested limits on file growth and code comments. Suggested fix Add both rules with the wording requested by the maintainer. No related issue or PR was found in the GitHub search. ## What Changed - Add: "Do not submit a PR that moves a code file from less than 1,000 lines of code to more than 1,000 lines of code." - Add: "Do not submit a PR that includes code comments." ## Verification - Confirm both rules appear under PR Requirements (all PRs) in CONTRIBUTING.md. - `git diff --check origin/master...HEAD` passed. - Greptile passed on commit `8cc5cd4be63cfbb16b3265b39e487581387bc3d0` with 5/5 and no actionable findings. - Local `pnpm -r typecheck`, `pnpm test:run`, and `pnpm build` were attempted. This worktree has no installed dependencies, so typecheck cannot resolve Node types and tests/build cannot load tsx. GitHub CI results will be checked before merge. ## Risks - Low risk. This change adds documentation only. - The wording states contribution policy without adding an automated gate. ## Model Used - OpenAI GPT-6 via Codex. Used reasoning, shell tools, and file editing. The exact runtime 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 (not applicable to this documentation-only change; the full commands were attempted but blocked by missing local dependencies) - [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-12 15:40:01 -05:00
DottaandPaperclip	f0e12c8519	Add managed Slack setup with an independent own-app path (#15679 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Slack connects a person to an agent through an installed app and a verified identity. > - Independent installations must remain usable without Paperclip Cloud or manager credentials. > - Approved Cloud deployments can use Slack manager grants to create and install each agent's app. > - Both paths should share credential storage, identity checks, recovery, and the existing runtime. > - This pull request adds gated managed setup and keeps independent app setup under Advanced. > - It also makes ongoing connection settings and personal test messages easier to use. ## Linked Issues or Issue Description Subsystem affected Slack setup, connection settings, tenant credential storage, and the Cloud connector handoff. Problem or motivation Approved deployments need an installation flow without pasted configuration tokens. Open-source users must retain their independent Slack app flow. A connection manager also needs a simple way to check a bot from Settings. Proposed solution Use the managed path when the instance is configured to support it. Choose agent and Connect are the two visible stops. Continue starts authorization or installation. Use your own app remains under Advanced before creation. Save personal manager grants by company, Paperclip user, Slack user, workspace, and manager app. Reuse only verified identities for test messages. Unknown identities must complete a private Slack connection challenge before linking and receiving the test DM. Alternatives considered A shared bot would change each agent's Slack identity. Requiring Slack CLI or a hosted service for self-hosted users would remove independent installation. Roadmap alignment This maintainer-requested change improves Connected Apps and experimental Agent Chat. It adds provisioning and management controls to the existing Slack runtime. Additional context The companion Cloud broker profile is a separate deployment prerequisite. Managed setup remains gated. Existing-app adoption is deferred. ## What Changed - Extract Slack registration, provider requests, completion, customer-owned setup, managed setup, and personal manager grants into focused services. Preserve the compatibility facade and independent removal cleanup. - Add company-scoped manager grants and a registration reference through an additive, idempotent migration after current master. Keep runtime credentials separate from app-registration secrets. - Add authenticated manager authorization, sealed handoff, serialized refresh and revocation, app creation, managed installation, and installer-bound OAuth fallback. - Preserve creation intent, block automatic uncertain recreation, save credentials before downstream checks, and validate app, workspace, bot, scopes, and installer identity. - Add the two-stop production wizard and ordered stories. Keep the own-app, manual, existing-app, and legacy-draft paths. - Simplify Settings. Open Slack configuration targets the saved app. The test-message action has its own row. Remove the old manual-avatar section, channel-message section, and broken permissions link. - Add paginated account discovery and a private connection challenge for unknown accounts. Expired invitations stop waiting and offer a new private invitation. Save send receipts before provider dispatch and preserve confirmed delivery when activity logging fails. - Reinstall the saved managed app on explicit reconnect, replace revoked credentials, and resume completion. Persist reconnect intent and duplicate-request receipts without creating another app. - Update provider browser tests, recovery tests, secret redaction, setup documentation, and the agent prompt. Preserve current master's durable verification scheduling. ## Verification - Full workspace typecheck and repository build passed on `56d389d47a`. The subsequent reconnect retry fix in `288364eada` also passed UI typecheck and UI build. - 114 focused Slack registration cases and 13 production managed-wizard cases passed, including fresh-token reconnect, retry after installation failure, and duplicate reconnect requests. - All nine affected Slack browser cases passed against the production UI and a disposable fixture server. They cover managed setup, automatic setup, own-app selection, refresh, recovery, mobile behavior, and connection settings. - Eight focused real-database test-message cases passed. They cover a private ownership challenge, saved grant reuse, account pagination, revoked and conflicting links, workspace mismatch, disabled DMs, revoked membership, audit failure, ambiguous dispatch, and secret canaries. - UI token gates and the production Storybook build passed. - Greptile reviewed exact head `288364eada5d9c114fad991ff634612639d06672` at 5/5 with no actionable findings or unresolved review threads. - The full repository test suite and current-head CI are running. Their final results will replace this line before merge. - Earlier live feature previews created two bots in the authorized Paperclip Slack workspace and reused one personal manager grant. Local managed Continue created and installed a bot without a configuration token or a separate Add to Slack action. Avatars, welcome DMs, signed callbacks, and direct replies were observed. A Settings test DM also arrived in the signed-in user's Slack account. - Earlier staging thread qualification required manual publication recovery for one bot. Current-head live qualification remains required before enabling the production default. Fixture results do not establish Slack approval behavior in other workspaces. ## Risks - Personal manager tokens can create apps. They stay in scoped vault entries. The manager client secret stays at the broker. Company, actor/session, origin, and app identity checks apply throughout setup. - The additive migration must also work on qualification instances that applied earlier branch migrations. Table, column, index, and constraint creation is idempotent. - Creation and message timeouts can leave uncertain outcomes. Saved request IDs prevent automatic duplicate dispatch. - Unknown Slack identities must receive and complete their private challenge while signed in. Account selection alone does not grant Paperclip permissions. Existing revoked or conflicting links are not overwritten. - A development-only manager transport uses an explicitly configured private credential file for local qualification. Production ignores this transport; no manager credentials are bundled with open source. - Managed rollout requires Slack approval, the companion broker deployment, configured secrets, and final live qualification. Removing a connection does not delete its Slack app. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, code execution, and browser tools. The session does not expose the 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 - [ ] 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> canary/v2026.1012.0-canary.13	2026-10-12 15:34:02 -05:00
DottaandPaperclip	7d9b93aee2	docs: establish paired feature and agent access maps (#16025 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Contributors use the feature map to understand and verify product capabilities. > - Agents need APIs and usable entry points within their permission boundaries. > - Product recipes and agent access need separate records with shared capability IDs. > - This pull request establishes that contract and gives maintenance ownership of both maps. > - The benefit is repeatable access review without changing product behavior or permissions. ## Linked Issues or Issue Description Refs: #15983, which added the portable verification skills and updated the feature map. This is its contract-only follow-up. Related: #15288 added the original feature map. Issue type Missing documentation and maintenance contract. Where is the issue? The product map, its missing agent access companions, and the verification skills. What's wrong? There is no shared convention for API presence, agent entry points, permission boundaries, access gaps, or evidence. An API declaration does not prove that a permitted native or remote agent can use it. Suggested fix Keep the product and agent access maps as siblings under `maps/`. Reuse capability IDs. Record representative source inventory separately from operation review and live proof. Keep both maps aligned through the maintenance skill. ## What Changed - Move the existing product map to `maps/feature-map/`. Preserve its recipes and Poteto format. Update relative links and add companion links. - Add `maps/agent-access-map/` with 35 area files and 171 matching capability IDs. Seed representative API operations, agent paths, policies and known gaps from the reviewed source inventory. Mark entries as `baseline`, `source-only`, and live verification `not-run`. - Define the shared contract in `maps/README.md`. Track API presence, agent availability, policy, evidence and review depth separately. Require operation enumeration before marking a broad capability operation-reviewed. - Extend `maintain-verification-skill` to reconcile both maps and inspect actual route policy and production tool admission. Update creation, verification, notices and contributor references to use the shared contract. - Add `scripts/check-maps.mjs` and ten regression tests. Check matching areas/IDs, indexes, references, contract fields, API method/path examples, justified exceptions and evidence-state consistency. - Keep the coverage inventory unchanged. Preserve skill invocation policies and both MIT license blocks. No product API, permission, UI, runtime helper, migration, dependency or workflow changes. ## Verification - Passed: `node scripts/check-maps.mjs` reports 35 paired areas and 171 matching capability IDs. All local map references resolve. - Passed: `node --test scripts/check-maps.test.mjs` runs ten tests. Fixtures cover missing companions, renamed/orphan/duplicate IDs, broken references, missing operation fields, empty exceptions, missing API examples, empty policy fields, and verified evidence without passed verification. - Passed: metadata validation for all three verification skills. Skill and contributor links resolve. Invocation policies and both license blocks are unchanged. - Compared relocated recipes with current master. Contents differ only in relative links and companion links. `coverage.json` is byte-for-byte unchanged. Master's updated read-only interaction test reference is retained. - Passed: `git diff --check`. The branch starts from current master and contains only this contract change. - Repository-wide typecheck, tests and build were not run locally for this documentation and Node structural-check scope. Live agent access was not exercised. Those gaps are explicit in the baseline entries; the structural check does not certify behavior. CI and automated review are pending. ## Risks - The companions are representative source baselines. They are not complete operation inventories or passed agent journeys. - The checker cannot establish actual permissions, native tool admission, operation completeness or truthful live evidence. Maintenance must inspect source and verify with the actual permitted agent context. - External links to the old product-map directory may need updates. Repository references have been updated. - Existing access gaps and board/user restrictions remain recorded. This contract does not change authority or implement missing paths. ## Model Used OpenAI GPT-6 through Codex assisted with this change. The session does not expose the exact serving model ID, configured context-window size, or reasoning setting. Capabilities used: source analysis, file edits, shell commands, and structural regression 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 - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-12 14:52:28 -05:00
Devin Foley Paperclip Claude Opus 5.5	4b766b8729	fix(acpx): record turn activity at the moment a stop fires (#15962 ) Record stop-time ACP turn diagnostics (last-event age, oldest pending tool age, pending tool kinds) so wall-clock timeout events show whether the turn was stalled. Diagnostics only. Co-Authored-By: Paperclip <Paperclip-Paperclip@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> canary/v2026.1012.0-canary.12	2026-10-12 12:33:59 -07:00
DottaandPaperclip	0d0e138dad	refactor(chat): extract channel status, receipts, drafts and authority workflows (#15995 ) ## Thinking Path > - Paperclip manages AI agents and their work. > - Chat channels connect that work to provider conversations. > - Provider workflows still fill the shared service. > - Their authority and recovery rules need clear homes. > - This PR lands five reviewed extractions into channel folders. > - Shared authorization, state and worker lifetime stay explicit. ## Linked Issues or Issue Description Refs #15976, #15996, #15999, #16001 and #16002. This root PR now contains all five extractions from batch three. The four upper PRs were merged into their parents. The combined tree matches reviewed stack head `789e918b5af49ec1958076ce4d22d31006205302` exactly. ## What Changed - Extract Slack session status and accepted-file receipt recovery. - Extract Telegram publication drafts and Stop handling. - Extract Photon events and native responses. - Extract Teams file-transfer authority. - Reduce `chat-channels.ts` from 29,897 to 26,461 lines (3,436 lines, 11.5%). - Preserve function bodies, runtime-map identity, leases and transaction boundaries. ## Verification - All 117 selected public-service cases passed before and after their respective extractions. - All 30 moved declarations and remaining service statements preserve normalized syntax across the five slices. - Server typecheck, module boundaries and whitespace checks passed. - Cumulative `pnpm -r typecheck` and `pnpm build` passed. Combined-head CI and review are pending on `5de1b0b99d71049a72440e8c131bf4bb30bdf3f3`. - Fixtures exercise assembled services and disposable databases, not live third-party providers. - Cumulative local `pnpm test:run` on `789e918b5af49ec1958076ce4d22d31006205302` exited 1: 32,414 passed, 125 skipped, one failure. `company-skills-routes.test.ts:1691` (`stars, forks, and comments on skills through company-scoped endpoints`) failed with `socket hang up`; that test and its route are unchanged by this stack. The same 58-case suite then passed in isolation without code changes. The original command did not reach 111 later serialized suites; its failure is retained, so the full-local-test checklist remains unchecked. ```sh pnpm exec vitest run server/src/__tests__/chat-channels.integration.test.ts -t 'Slack session\|Slack turns to Idle\|signed Slack session stop\|denies guest Slack stops' ``` - Combined-head CI attempt 1: five runners received a shutdown signal at 19:13:08 UTC (server shard 10/12, serialized shards 2/9 and 7/9, E2E shards 3/8 and 7/8). These jobs stopped during execution without a failing test assertion. [Original workflow](https://github.com/paperclipai/paperclip/actions/runs/38293566028). The affected jobs will receive one unchanged retry after the other jobs finish. ## Risks - Changes cross durable provider recovery and authority boundaries. The moved bodies preserve syntax, and 117 focused public-service cases passed before and after their extractions. - Shared workers, timers, runtime maps and generic authorization remain in the service. - The full local test run failed in an unchanged company-skills route test; its result and the unrun suites are recorded above. ## Model Used OpenAI Codex, GPT-6 family, with reasoning and repository tools. The exact runtime model ID and context-window size are not exposed in this session. No separate agent was 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 - [ ] 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>	2026-10-12 19:26:54 +00:00
DottaandPaperclip	cc88b61c09	feat: add portable verification skills and refresh the feature map (#15983 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Contributors use the feature map to select verification recipes. > - The repository needs separate skills to create a verifier, maintain recipes, and run checks. > - Shared recipes must match current routes, controls, and prerequisites. > - This pull request adds portable verification skills and updates the existing map. > - The benefit is a repeatable verification workflow with clear ownership and evidence limits. ## Linked Issues or Issue Description Refs: #15288, which added the existing feature map. The related test cleanup in #15978 changes test ownership; this PR changes skill instructions and recipes. Issue type Missing documentation and outdated verification instructions. Where is the issue? The project-local skills in `.agents/skills/` and the recipes in `feature-map/`. What's wrong? The repository lacks the portable creation and maintenance skills. The verifier mixes live verification with map editing. Some recipes describe old controls or omit required flags, identities, and provider setup. Suggested fix Import the skills and their complete references from Paperclip's pstack fork. Keep the existing map in its current directory. Let the verifier read recipes and report drift. Let the maintenance skill update the map. ## What Changed - Add `create-verification-skill` and `maintain-verification-skill` from the portable fork of Poteto's pstack. Include invocation policies, all feature-map examples, self-contained attribution notices and the full MIT license in each skill folder. - Use the existing `feature-map/` directory and Poteto's recipe format. Omit the fork's separate runtime skill and runtime-skill dependencies because Paperclip supplies execution. - Add `verify-paperclip` with executable launch, readiness, onboarding, and cleanup helpers. Use isolated temporary data and separate evidence directories. - Make `verify-paperclip` consume the map and report recipe drift. Give map editing to `maintain-verification-skill`. - Review all 35 feature files and correct 30 recipes. Clarify routes, flags, current controls, persistence scope, and the limits of linked tests. - Remove the unrelated Conference Room flag change from the onboarding smoke helper. - Add a standard-library ownership test. It proves that doctor and stop reject a foreign checkout without stopping its live server. A delayed-exit fixture also proves cleanup waits for runtime exit. - Keep audit screenshots and scratch reports outside the repository. No product code, migrations, lockfile, or workflow changes. ## Verification - Passed after rebase: metadata validation for all three skills, Python syntax and executable checks, JavaScript syntax, 35-entry map/index consistency, relative links, license preservation, and `git diff --check`. - Ran one isolated live audit before rebase. Checked task persistence, document upload/download bytes, goal hierarchy, project edits, search, local process Agent Chat, question replies, queued-message discard/stop, and a harmless loopback MCP call. - Checked local settings and draft flows. Synthetic cost events reached a small budget limit and paused the test agent. These checks do not prove external model quality or provider billing. - Checked cleanup of the audit server, database, local MCP fixture, and workspace service inventory. - Passed: `pnpm -r typecheck`. - Greptile: 5/5 on commit `4344ac4df7`. The cleanup finding is fixed and its review thread is resolved. A fresh review is pending for the notice relocation. - Passed: `python3 -m unittest discover -s .agents/skills/verify-paperclip/tests -v`. Both tests pass: the foreign fixture stayed alive after rejection, and owned cleanup waited for delayed runtime exit. - Passed: `pnpm build`. - All GitHub CI checks were green on commit `4344ac4df7`. The cloud-auth browser shard passed after one retry for a disposed mocked API response. The notice relocation passed skill metadata, relative-link, and license-preservation checks; fresh CI/review is pending. - The full local `pnpm test:run` did not complete. It was interrupted after nearly 30 minutes once the complete CI suite passed on the same commit. Exit code: 130. The new helper safety tests passed locally. The local full-suite checklist item stays unchecked. - Full live coverage is incomplete. Authenticated multi-user checks and external provider journeys need their own identities, credentials, and targets. - The corrected onboarding helper could not be re-tested after removing the flag mutation. Two fresh launches failed before server startup. Direct PostgreSQL initialization reported exhausted shared-memory IDs or limits. The host had free disk space. No host-wide limits or unrelated instances were changed. ## Risks - Recipe drift can return as the UI changes. The map records verification scope, not proof of a passed journey. - The new helpers assume a source checkout with installed dependencies, Python, Node, and `lsof`. The onboarding helper also needs Playwright. - The local audit found observations that need separate investigation: an action test returned fixture data while the connection control showed Off and native profiles existed; a failed status-card setup task left the card showing Setting up. Workspace service start also did not reach a running state. This PR does not change product behavior or redefine those outcomes as success. - The main audit trace did not finalize during browser shutdown. Screenshots, text captures, and iteration results were retained. - Live evidence was captured before rebase. The onboarding helper re-test and full provider/auth qualification remain incomplete. ## Model Used OpenAI GPT-6 through Codex assisted with this change. The session does not expose the exact serving model ID, configured context-window size, or reasoning setting. Capabilities used: source analysis, read-only source subagents, file edits, shell commands, and browser automation. ## 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 --------- Co-authored-by: Paperclip <noreply@paperclip.ing> canary/v2026.1012.0-canary.11	2026-10-12 13:31:44 -05:00
Devin Foley devinfoley Claude Fable 5.1	8227485372	perf(ci): cache the Runner's release crate artifacts keyed by their inputs (#15932 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Its trusted PR workflow builds the Runner's Rust binary in five jobs: Typecheck + Release Registry, Build, Canary Dry Run, and the `rust` and `vitest 2/2` lanes of Verify Paperclip Runner. The `Build` job is the slowest check in almost every green run (461s, 489s and 515s in runs 38180574768, 38182717052 and 38183149920 on 2026-10-11). > - Each of those jobs restores master's `release-runner-v2` dependency cache. That cache holds only third-party crates. `rust-cache` removes workspace crates when it saves, and a fresh checkout invalidates cargo's mtime fingerprints for workspace crates in any case. So cargo compiles `paperclip-runner-core` in release mode from scratch on every run. The job logs show one `Compiling` line and 28s to 49s for it. > - 18 of the 239 commits on `master` in the seven days before this change touched the crate's inputs. The other 221 compiled the same sources to the same binary again. > - This pull request adds a second cache that holds only that crate's release artifacts (about 70 MB). The key is made from the compiler, the checkout root and a hash of every input the build reads. The master Rust lane writes it. A pull request whose merge tree has byte-identical inputs restores it and marks the artifacts newer than the checkout, so cargo keeps them. Every other pull request misses and compiles as before. > - The benefit is about 28s to 49s less on `Build`, which is the run's critical path, and the same on Typecheck, Canary Dry Run and two Runner lanes, for about nine of ten pull requests. ## Linked Issues or Issue Description No GitHub issue exists for this. The description below follows the enhancement template. What existing behavior does this improve? The time the trusted PR workflow spends to compile the Runner's own crate on every run. Subsystem affected CI / build Current behavior Every PR job that builds the Runner binary compiles `paperclip-runner-core` in release mode from scratch. The compile takes 28s to 49s on the `runs-on` fleet (one `Compiling paperclip-runner-core` line, then `Finished release profile` in runs 38169436532 to 38183149920 on 2026-10-11). The shared Rust cache cannot help: it holds only third-party crates, and a fresh checkout gives every source a new mtime, which makes cargo discard the crate's fingerprints. Proposed behavior The master Rust lane in `release-verify.yml` saves the crate's release artifacts under a key made from the compiler, the checkout root and a hash of every input the release build reads. The PR jobs that build the binary restore that entry read-only. On a hit, a script sets the mtime of every restored artifact to now, so cargo sees every source as older than the build and keeps the artifacts. `pnpm build` then prints `Finished release profile` in under a second for that crate. On a miss, cargo compiles the crate exactly as before. Reason and benefit About 28s to 49s off `Build`, the slowest check in almost every green run, and the same off the Typecheck, Canary Dry Run and two Verify Paperclip Runner lanes. The saving applies to every pull request whose merge tree does not change the crate's inputs, which was 221 of 239 `master` commits in the week before this change. Breaking changes None. The checks are unchanged. A miss or an eviction costs the compile time it costs today and nothing else. Additional context This is a workflow change. `pr.yml` calls `pr-trusted.yml@master`, so this pull request's own run uses the current reader steps, and the writer runs only on a master push. The saving becomes visible on the first PR runs after the merge and after the next master push has written the entry. ## What Changed - `scripts/runner-release-crate-cache.mjs` (new): the one place that defines the cached path list (`CACHED_PATHS`), the hashed inputs (`HASHED_INPUTS`) and the files a restore must contain (`REQUIRED`). The `scope` subcommand prints the platform, the `rustc --version --verbose` release, commit and host, and a hash of the checkout root. The `mark-current` subcommand sets the mtime of every restored artifact to now and prints a `paperclip.runner-release-crate.v1` JSON line with the file count and bytes. If the restored set lacks any of the seven files cargo's freshness check reads or checks for (the fingerprint hash and dep-info of each unit, the lib's rlib and rmeta, the binary under `deps`), it removes the restored files, prints `action: discarded` naming the missing file, and exits 0, so cargo compiles as on a miss. - `.github/workflows/pr-trusted.yml`: after the `release-runner-v2` restore in `typecheck_release_registry`, `build` and `canary_dry_run`, and in the `rust` and `vitest 2/2` lanes of `verify_paperclip_runner` (new matrix key `release_crate: true`), three steps: compute the key scope, `actions/cache/restore` the crate under `runner-release-crate-v1-<scope>-<hashFiles(...)>` with no `restore-keys`, and run `mark-current` when `cache-hit == 'true'`. The `hashFiles` list covers the toolchain pin, the manifests and lockfile, the crate sources, the protocol tree and the three fixture trees the test modules include (two under the Runner package and `tests/runner-e2e/fixtures` at the repository root). - `.github/workflows/release-verify.yml`: in the Rust lane of an own-repository master push, after the debug warm-up: compute the key scope, look the key up (`lookup-only: true`), and on a miss run `cargo clean --release -p paperclip-runner-core` and `pnpm build:binary` (the exact command the readers run, so the entry carries no test-profile variants), then `actions/cache/save` the same path list under the same key. - `scripts/__tests__/runner-release-crate-cache.test.mjs` (new, 10 tests, in `test:release-registry`): the path list and hashed inputs are the expected ones and exist; every `include_str!` and `include_bytes!` in the crate sources resolves under a hashed input, whether its argument is a literal or a `concat!` of literals, `env!("CARGO_MANIFEST_DIR")` and macro metavariables, and any other form fails the test by name (this guard found the `test/fixtures` tree during development and the `tests/runner-e2e/fixtures` tree in review); the parser itself is tested on a synthetic crate for each supported form and six rejected ones; every PR reader restores after the dependency cache and marks before its build command with the script's exact path list and key and no `restore-keys`; the Verify lanes are gated by `release_crate`; the writer runs after the checks with the lookup, the clean and build, and the save under the readers' exact path list and key; the scope changes with the compiler and the checkout root and survives a missing `rustc`; `mark-current` makes every artifact newer than the checkout, leaves a dependency's artifacts alone, discards a restore missing any one of the seven required files (one case each, checking the named reason), and still marks a restore missing any one of the seven files cargo does not need. ## Review fixes Greptile's two findings on the first commit were both valid and are fixed in the second commit: - Incomplete caches looked usable. `REQUIRED` checked four files, but cargo's freshness check needs seven. Measured with cargo 1.97.1 on the real crate (restore, touch the artifacts, delete one file, build): without the lib's fingerprint hash, dep-info, rlib or rmeta it recompiles the crate (24s to 27s); without the bin's fingerprint hash, dep-info or the binary under `deps` it relinks (1.5s); without either `.json` fingerprint record, either rustc `.d` file, the uplifted binary or its `.d` it reports the crate fresh in 0.15s and recreates the uplifted binary from `deps`, and the staging step then copies it. `REQUIRED` now lists exactly the seven files, the glob for the binary under `deps` excludes the `.d` beside it, and the test removes each of the seven in turn (discarded, naming it) and each of the other seven in turn (still marked). - Composed include paths escaped the guard. The regex matched only `include_str!("literal")` and skipped `include_str!(concat!(...))`, which the crate uses four times (30 of 34 includes were checked). The guard now parses every include argument and resolves the `concat!` forms; one of them, in `provider_events.rs`, reads `tests/runner-e2e/fixtures/native-completion/terminal-tool-carrier.json` at the repository root, outside every hashed input. It is test-only, so today's release binary does not read it, but the key is meant to cover every include whatever its build, so `tests/runner-e2e/fixtures/*` (9 files, 80 KB) joins `HASHED_INPUTS` and the six key embeddings in the two workflows. With the first commit's input list, the new guard fails on exactly that include. - `doc/RELEASE-AUTOMATION-SETUP.md`: a "Runner release crate cache" section under the Runner verification dependency cache, with the key, the writer, the readers and the trust boundary. - `package.json`: the new test file in `test:release-registry`. ## Verification - `node --test scripts/__tests__/runner-release-crate-cache.test.mjs`: 10 tests pass, three consecutive runs. - The second commit, with the real toolchain on the real crate (`rustc 1.97.1`, cold build 2m20s, the crate's artifacts 74 MB): every source touched to a fresh-checkout mtime and the archived artifacts restored, cargo compiles (`Compiling paperclip-runner-core`, 24.8s and 25.1s, the two controls); restored and marked by `mark-current`, `Finished release profile in 0.16s` with no `Compiling`, and the same on a second build. Then, for each of the fourteen files cargo wrote for the two units, one at a time: restored, marked and that file deleted, cargo recompiles without any of the seven `REQUIRED` files and reports fresh without any of the other seven; restored with that file deleted and run through `mark-current`, the seven required ones print `action: discarded` naming the file and the others print `marked`. A restore holding only the seven required files builds fresh in 0.15s, cargo recreates the uplifted binary, and `stage-runner-binary.mjs` copies it into `dist/bin`. - `node --test '.github/scripts/tests/.test.mjs'`: 378 of 381 pass. The 3 failures are in `docker-canary-promotion.test.mjs` and fail the same way on an unmodified `master` checkout in this sandbox (the stand-in docker writes no `calls.jsonl`). - `node --test scripts/__tests__/release-verify-workflow.test.mjs scripts/__tests__/e2e-shard.test.mjs scripts/__tests__/run-vitest-stable-shard.test.mjs`: 99 of 101 pass; the 2 failures spawn `pnpm`, which is not on this sandbox's PATH, and fail the same way on `master`. - Both workflows parse as YAML. No job has a duplicate step name or step id. - The mechanism, with the real toolchain (`rustc 1.97.1`, the package's pin) on a copy of the crate: a cold `cargo build --release -p paperclip-runner-core --bin paperclip-runnerd` (2m23s here). Then the artifact set was archived with `tar`, removed, every source re-copied so each had a new mtime, and the set restored: - restored, not marked: `Compiling paperclip-runner-core`, 24.6s (the control; this is what CI does today); - restored and marked by `mark-current`: `Finished release profile in 0.15s`, no `Compiling`; a second build is the same; - one Rust source edited after a marked restore: `Compiling`, 24.0s; - one protocol schema edited after a marked restore: `Compiling`, 23.9s (the protocol files enter cargo's dep-info as absolute paths and are hashed into the key); - the rlib removed from a restored set: `mark-current` prints `action: discarded, reason: incomplete: the lib rlib is missing` and removes the rest, and cargo compiles. - Not run here: the workflow steps themselves. `pr.yml` pins `pr-trusted.yml@master`, so this pull request's own `Build` job runs the current reader steps, and the writer runs only on a master push. The first PR runs after the merge and after the next master push show the `Restore the Runner release crate` step's result and the `paperclip.runner-release-crate.v1` line in their `Build` logs. ## Risks - Correctness: a reader can only restore artifacts that master built from inputs byte-identical to its own merge tree, because every input the build reads is in the key, and the key has no prefix match. A pull request cannot write. The trust boundary is unchanged: master writes, a pull request restores master's entry. - An input the build reads that is outside the hashed patterns would let a stale artifact pass. The release dep-info lists the crate sources and the protocol schemas and fixtures; all are hashed. The guard test resolves every `include_str!` and `include_bytes!` in the crate, literal or `concat!`, and fails if one lands outside the hashed inputs or uses a form it cannot resolve, so a new include form cannot slip past it by not matching a regex. - GitHub-hosted runners check out under `/home/runner/work`, the `runs-on` fleets under `/home/runner/_work`. Cargo records the included protocol files as absolute paths, so an entry from one root is useless under the other. The checkout root is in the key, so the other root misses instead of restoring something cargo then discards. - A cache that does not keep mtimes on restore changes nothing: the artifacts are then already newer than the checkout, and `mark-current` sets them to now in any case. - Cost: one new entry of about 70 MB per distinct input set, written only by the master Rust lane on a miss, plus one `cargo clean` and `build:binary` (about 40s to 50s) on that lane when the inputs changed. The readers pay one restore of about 70 MB (two to three seconds at the fleet's observed restore speed) and a sub-second `mark-current`. - An incomplete entry (a writer that saved a partial set) is discarded by `mark-current` and costs one compile, the same as a miss. ## Model Used - Claude (Anthropic), model id `claude-fable-5-1` (Claude Fable 5.1), extended thinking, with tool use (shell, file editing, GitHub CLI, a local Rust toolchain for the experiment) in a Paperclip agent 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 - [ ] 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-10-12 11:25:31 -07:00
Devin Foley devinfoley Claude Fable 5.1	7df517d18f	perf(build): reuse a current Runner build in the server's prepare:runner-vendor step (#15926 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Its CI runs a `Build` job on every pull request. That job runs `pnpm build` and then verifies the public npm install. Since the server test shards got faster, `Build` is the slowest check in most runs (419-497s on the six fully green `master` runs created 2026-10-11 19:46Z to 20:17Z). > - Inside `pnpm build`, the server package is the last package to build. Its first step, `prepare:runner-vendor`, runs the full build of `@paperclipai/paperclip-runner` so the server can vendor `packages/paperclip-runner/dist`. In `pnpm -r build` that package was built seconds earlier by the same command. The second build took 12-16s on those six runs and sits on the critical path of the job. > - The step cannot just be removed. A standalone `pnpm --filter @paperclipai/server build` (the Dockerfile's path) must produce a current vendored Runner on its own. > - This pull request keeps that guarantee and skips only the build that is provably redundant. The Runner's `build` records a digest of its inputs, captured before its first step and confirmed after its last, together with a manifest of every file it left under `dist`. The server's `prepare:runner-vendor` reuses the build when the digest matches, the stamp is for this platform, and every recorded output is still there at its recorded size. Any other state runs the same full Runner build as before. > - The benefit is 12-16s off the `Build` job and off every other `pnpm build` (the Canary Dry Run's `release.sh` build, local builds), with no change to what a standalone server build produces. The PR's own first run measured it: the server step reused the build in 56ms where `master` runs rebuilt for 11-15s. ## Linked Issues or Issue Description No GitHub issue exists for this. The description below follows the enhancement template. What existing behavior does this improve? The server build's `prepare:runner-vendor` step, which builds `@paperclipai/paperclip-runner` so the server can vendor its `dist`. Subsystem affected Build and CI (`server/package.json`, `packages/paperclip-runner/package.json`, the `Build` job). Current behavior `prepare:runner-vendor` runs the Runner's full `build` every time. Inside `pnpm -r build`, the Runner was already built by the same command 20 to 25 seconds earlier, with every check passing. On six fully green `master` runs (2026-10-11, 19:46Z to 20:17Z) the repeated build took 11.8s to 15.9s, measured from the `server build$ pnpm run prepare:runner-vendor` log line to the Runner's `Finished release profile` line. The server package builds last, so that time is on the critical path of `Build`, which is the slowest check in most pull request runs. Proposed behavior - The Runner's `build` starts with `node scripts/record-build-inputs.mjs --begin` and ends with `node scripts/record-build-inputs.mjs --finish`. `--begin` removes the previous stamp and records a digest of every build input before the first step reads anything. `--finish`, after every step and check has passed, recomputes the digest and writes `packages/paperclip-runner/node_modules/.cache/paperclip-runner-build-inputs.json` only if the inputs are still the ones the build began with, together with the path and size of every file under `dist`. A stamp therefore exists only for a build that completed every step on inputs that did not move while it ran. - The server's `prepare:runner-vendor` becomes `node scripts/prepare-runner-vendor.mjs`. It reuses the build if the stamp is for this platform and architecture, every recorded output is still there at its recorded size, and the recomputed digest matches. In every other case it removes the stamp and runs `pnpm --filter @paperclipai/paperclip-runner build`, the exact command the step ran before. - `PAPERCLIP_RUNNER_VENDOR_REBUILD=1` forces the rebuild. Reason and benefit 12-16s off the `Build` job and off every other `pnpm build` (the Canary Dry Run's `release.sh` build, local builds), with no change to what a standalone `pnpm --filter @paperclipai/server build` produces. Breaking changes None. The rebuild path runs the same command as before. A fresh checkout, a changed input, a missing or truncated output, an edit that landed during the build, or a stamp from another platform always rebuilds. ## What Changed - `packages/paperclip-runner/scripts/build-inputs.mjs` (new): defines the input set, the digest, the output manifest and the reuse decision. Inputs are every file under `packages/paperclip-runner` except `dist`, `dist-browser`, `runner/target`, `node_modules` and dot-directories; every file under `packages/paperclip-eval-kernel` except `dist` and `node_modules` (the Runner's `build:typescript` builds it first); every file under the root `patches` directory (`check:acpx-profiles` hashes `acpx@0.13.1.patch`, and `build-verified-provider-entrypoints.mjs` copies the `pi-acp` and `brace-expansion` patches into `dist/cli/pi-provision-inputs`); and the root `package.json`, `pnpm-lock.yaml`, `pnpm-workspace.yaml` and `tsconfig.base.json`. The toolchain pins are inside the package (`rust-toolchain.toml`, `runner/Cargo.lock`) and the TypeScript version is in the lockfile, so both are covered. A symlink is hashed as its target path and is not followed. Outputs are every file under `dist`, the tree the server copies wholesale, recorded with their sizes. Exports `beginRunnerBuild`, `recordRunnerBuild` and `assessRunnerBuild` (returns `current` plus a stable reason code: `no_stamp`, `schema_mismatch`, `platform_mismatch`, `missing_output`, `outputs_changed`, `inputs_changed`, `inputs_unchanged`). - `packages/paperclip-runner/scripts/record-build-inputs.mjs` (new): the two phases, `--begin` and `--finish`, added as the first and last step of the Runner's `build` in `packages/paperclip-runner/package.json`. Each build chain has its own pending record under `node_modules/.cache/paperclip-runner-build-inputs.pending/`, named after the shell pnpm runs the chain in (the parent of both phases; `--finish` also accepts a record named after its own pid, for a shell that execs the last command of the chain), so two Runner builds running at once in one checkout do not consume each other's record. `--finish` without a pending record for its chain is an error, so the chain cannot silently lose its first step; `--finish` after an edit that landed mid-build prints `not recorded: inputs changed while the build ran` and leaves no stamp. Records of builds that never finished are pruned by the next `--begin` after a day. - `server/scripts/prepare-runner-vendor.mjs` (new): the reuse-or-rebuild step. It resolves the pnpm that is running it through `npm_execpath` with the same rule as the CLI's `resolvePnpmInstallInvocation` (a JavaScript entry runs through this Node, a native executable runs directly, otherwise `pnpm` on PATH). It prints one `paperclip.runner-vendor.timing.v1` line with `action`, `reason`, `check_ms` and `build_ms`, so the saving is measured on this PR's own `Build` job. - `server/package.json`: `prepare:runner-vendor` now runs that script. The `build` and `typecheck` scripts are unchanged. - `server/src/__tests__/server-package-build-script.test.ts`: pins the new indirection and the command behind it (imported from the script, so the Dockerfile's standalone path stays pinned), and a new test asserts the Runner's `build` starts with `--begin`, ends with `--finish`, and has exactly those two record steps. - Tests: `packages/paperclip-runner/scripts/build-inputs.test.mjs` (node:test, added to `test:typescript:prep`) and `server/scripts/prepare-runner-vendor.test.mjs` (vitest, in the server lane). - `doc/DEVELOPING.md`: a "Reused Runner build in the server build" section under Test Commands. ## Review findings on the first head, all fixed in [`2d57542`](https://github.com/paperclipai/paperclip/pull/15926/commits/2d575425977f87b4612222d0a1961bc9cc5ba569) Greptile scored the first head 2/5 with three P1 findings. All three were valid. \| Finding \| Fix \| \| --- \| --- \| \| Patch edits leave stale output. The root patch files the build reads were not in the digest. \| Every file under the root `patches` directory is an input. Tests assert the patches are in the input list and that editing the pi-acp patch, the acpx patch, or adding a patch changes the digest. \| \| Missing helpers pass the build. Only four outputs were checked, so a `dist` that lost `dist/cli/acpx-runtime-sidecar.cjs` still counted as current. \| `--finish` records the path and size of every file under `dist`; reuse requires all of them intact and reports `outputs_changed` naming the first missing or resized file. Schema bumped to `paperclip.runner-build-inputs.v2` so an older stamp is rejected. Tests cover a deleted helper, a truncated helper, and the server step rebuilding on `outputs_changed`. \| \| New edits count as compiled. The digest was hashed after the build, so a source edited while `build:binary` ran was recorded as compiled. \| The build is bracketed: `--begin` captures the digest before the first step, `--finish` compares after the last and writes nothing if it moved. Tests cover the mid-build edit, the undisturbed build, and the CLI in both orders. \| ## Review finding on the second head, fixed in the third commit Greptile scored the second head 4/5 with one P1, valid: two Runner builds running at once in one checkout (server `build` beside `typecheck`) shared one pending record, so the second `--begin` overwrote it, the first `--finish` consumed it, and the second `--finish` threw `no pending build inputs` after every step of its build had passed. Reproduced on the second head's module: two `beginRunnerBuild`, then the first `recordRunnerBuild` records and the second throws. \| Finding \| Fix \| \| --- \| --- \| \| Overlapping builds fail each other. One pending file for every build chain. \| One record per chain, named after the shell pnpm runs the chain in: `--begin` sees it as its parent, and so does `--finish`, unless the shell execs the last command of the chain (bash can), in which case `--finish` is that shell and finds the record under its own pid. Pending records of builds that never finished are pruned after a day. An edit between two overlapping starts leaves no stamp whichever build finishes last: the build that began before the edit reports `inputs_changed_during_build` and removes the stamp the other wrote, so a stamp always means every build that wrote `dist` read the inputs it names. Tests: both finishing orders with and without an edit, the pruning, a `--finish` that cannot use another chain's record, and two real `sh -c` chains (plus one under `bash`) held open at the same time, both recording. On the real repo, two `pnpm --filter @paperclipai/paperclip-runner build` chains started 8s apart with a cargo stand-in both recorded (`files=1223 outputs=1434`) and left the pending directory empty. \| ## Measured on this PR's runs The `Build` job ran `pnpm build` from the branch, so both builds of the Runner in that job used the new chain. First head (`c23faab`, run 38175281058), against the four fully green `master` runs created 20:41Z to 21:37Z the same evening: \| \| PR run 38175281058 \| `master`, four runs \| \| --- \| --- \| --- \| \| Runner build inside `pnpm -r build` \| 55.3s \| 47.3-62.0s \| \| Server step `prepare:runner-vendor` \| `action:reuse,reason:inputs_unchanged,check_ms:56,build_ms:0` \| full Runner rebuild, 11.0-14.8s \| \| Server package build \| 29.7s \| 32.3-43.5s \| \| `pnpm build` step \| 114s \| 102-135s \| \| `Build` job \| 411s \| 409-474s \| Second head (`2d57542`, run 38178686999), against the two fully green `master` runs created in the same half hour (38178951607 and 38180574768): \| \| PR run 38178686999 \| `master`, two runs \| \| --- \| --- \| --- \| \| Runner build inside `pnpm -r build` \| 53.9s (`begin:` 22:03:04, `recorded:` 22:03:57, digest 460e02616081 over 1231 files and 1434 outputs) \| 62.2s, 64.6s \| \| Server step `prepare:runner-vendor` \| `action:reuse,reason:inputs_unchanged,check_ms:109,build_ms:0` \| full Runner rebuild, 14.5s, 15.2s \| \| Server package build \| 27.4s \| 43.5s, 44.8s \| \| `pnpm build` step \| 106s \| 91s, 95s to the Runner's end plus the rest; 127s, 135s in all \| \| `Build` job \| 405s \| 461s, 479s \| The rebuild is gone from the server build on both heads, and the check costs 56-109ms where `master` rebuilds for 11-15s; the rest of the spread between runs is runner speed on the `runs-on` fleet. The third commit changes nothing on the reuse path: it only changes where the pending record lives between `--begin` and `--finish`. ## Verification - `node --test packages/paperclip-runner/scripts/build-inputs.test.mjs`: 11 tests, three consecutive runs clean. Two builds at once in one checkout each keep their own pending record and both record, in either finishing order; with an edit between their starts the build that began before it leaves no stamp whichever finishes last. A build's start prunes records older than a day and no others. A `--finish` cannot use another chain's record. Two chains run by separate `sh -c` shells at the same time (and one under `bash`) both record and leave the pending directory empty. The input set is exactly the sources, the eval kernel, the root patches and the root config, and skips outputs and caches. The output manifest lists every file under `dist` with its size and nothing outside it. The digest is stable across reads, does not change when `dist`, `dist-browser`, `node_modules`, `.vite` or `runner/target` change, and does change for a Runner source, a Rust source, an eval-kernel source, the pi-acp patch, the acpx patch, a new patch, the lockfile, the base tsconfig, a new file and a rename. A symlink changes the digest but its target's files are not read. A build is current only with a matching v2 stamp, the same platform and architecture, the four named outputs present, and every recorded output intact (a deleted or truncated helper is `outputs_changed`; a file the build did not produce may appear). An input edited between `--begin` and `--finish` leaves no stamp and removes the pending record; the next build records normally. `--finish` without `--begin`, or after a build that left a required output missing, throws and leaves no stamp. The CLI brackets the build for the package it is pointed at, reports a mid-build edit, and rejects `--finish` first, both flags, neither flag, and unknown arguments. - `vitest run scripts/prepare-runner-vendor.test.mjs src/__tests__/server-package-build-script.test.ts` in `server/`: 21 tests. The decision reuses a current build, rebuilds a stale one, and rebuilds a current one only when `PAPERCLIP_RUNNER_VENDOR_REBUILD=1`. The pnpm resolver covers a JavaScript entry, a native executable, a Windows executable, no `npm_execpath`, and npm's `npm_execpath`. With an injected build command: a current stamp runs nothing and prints `action:reuse`; changed inputs run the exact command from `server/` with the stale stamp already removed; a lost `dist/cli/acpx-runtime-sidecar.cjs` rebuilds with `reason:outputs_changed`; a failing build returns its status and leaves no stamp. End to end, the CLI with a stand-in `pnpm` on PATH that brackets its build the way the real one does rebuilds on the first call, reuses on the second, rebuilds after a source change, rebuilds after a lost output, and reuses again. The guard test asserts `prepare:runner-vendor` is the new script, the rebuild command is still `pnpm --filter @paperclipai/paperclip-runner build`, the server build still starts with the step, and the Runner's `build` starts with `--begin` and ends with `--finish` with exactly two record steps; it fails against the previous build script on its first assertion. - Real repo, this checkout, with `cargo` and `pnpm` stand-ins on PATH (no Rust toolchain here; the stand-in writes the one file `stage-runner-binary.mjs` copies): `pnpm --filter @paperclipai/paperclip-runner build` ran the complete chain through the real nested pnpm (every TypeScript step and check, the stand-in cargo, the binary staging, the two binary-reading checks) and recorded `files=1223 bytes=18735059 outputs=1434`; the stamp is 128 KB. `pnpm run prepare:runner-vendor` in `server/` then printed `action:reuse,reason:inputs_unchanged,check_ms:222,build_ms:0`. Appending a newline to `patches/pi-acp@0.0.33.patch` made the assessment `inputs_changed`; truncating or deleting `dist/cli/acpx-runtime-sidecar.cjs` or `dist/cli/opencode-app-server-proxy.cjs` made it `outputs_changed` in 1-5ms; restoring each made it current again. `--begin`, an edit to `src/index.ts`, then `--finish` printed `not recorded: inputs changed while the build ran` and left no stamp. - The whole check on the real set (1223 inputs, 18 MB; 1434 outputs) takes 165-227ms on this host and took 56ms on the CI runner; the output manifest part is 1-5ms. - Not run here: the real `cargo build`, and `pnpm build` end to end. This PR's `Build` job runs `pnpm build` from the branch, so its log carries the Runner's `begin:` and `recorded:` lines and the server build's `paperclip.runner-vendor.timing.v1` line with the measured result. ## Risks - A build input outside the digest would let a stale Runner be vendored. The digest covers the whole Runner package except its outputs, the eval kernel the Runner builds first, the root patches, and the root files the Runner's tsconfig and dependency graph read. The lockfile covers dependency versions, and the pins inside the package cover the Rust toolchain. An input missed here is a bug to fix by adding it to the set; the fallback direction is always a rebuild, never a skip. - The whole `patches` directory is an input, although the Runner build reads three of its fourteen files. An edit to an unrelated patch therefore costs one extra Runner rebuild, which is the safe direction and avoids a hand-kept list of file names that could drift from the scripts that read them. - The stamp lives in `node_modules/.cache`, which pnpm does not manage and `.gitignore` and `.dockerignore` already exclude. It is about 128 KB with the output manifest. The Docker build has no stamp and no prior Runner build, so it rebuilds exactly as before. - A stamp is written only after the Runner's `build` passed every step on inputs that did not change while it ran. The Runner's first step and the prepare step both remove any existing stamp before a rebuild starts, so a build that stops partway, or a build command that fails before its first step, leaves no stamp. - `node scripts/record-build-inputs.mjs --finish` on its own is an error; the script is only meant to run as the two ends of the `build` chain, and the guard test pins that. - The pending record is keyed by the pid of the shell that runs the chain. pnpm runs every script through a shell (`sh -c` on POSIX, `cmd` on Windows), and both phases are children of that shell; a shell that execs the last command of the chain is covered by matching the finishing process's own pid too. A chain run some other way, with the two phases under different parents, fails loudly at `--finish` rather than recording. Two builds running at once still write the same `dist`, which no stamp can make safe; what the record guarantees is that a stamp is written only by a build whose own inputs did not move. - The platform and architecture are part of the comparison, so a stamp from another machine is never trusted; an older v1 stamp is rejected by schema. - The Typecheck job builds the Runner once, through this step, with no prior `pnpm -r build`, so it gains nothing and loses nothing: there is no stamp and it rebuilds as before. - The step now spawns pnpm through `npm_execpath` instead of relying on `pnpm` being on PATH, because under corepack the script shell has no `pnpm`. Outside a pnpm script it still falls back to `pnpm` on PATH. ## Model Used - Claude (Anthropic), model id `claude-fable-5-1` (Claude Fable 5.1), extended thinking, with tool use (shell, file editing, GitHub CLI) in a Paperclip agent 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 - [ ] 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-10-12 11:25:24 -07:00
Devin Foley devinfoley Claude Fable 5.1	0ea8ebd040	fix(test): make the vitest home teardown remove read-only runtime-context bundles (#15931 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Its CI runs the server test suite as twelve `General tests (server (n/12))` shards on every pull request. Each shard worker gets its own throwaway `PAPERCLIP_HOME` from `server/src/__tests__/setup-supertest.ts`, which removes it with a recursive `rmSync` at worker exit. > - That removal has been failing now and then with `EACCES, Permission denied: /tmp/.../paperclip-vitest-home-...` after every test file in the shard passed (four shard jobs on 2026-10-11 between 14:10Z and 22:10Z, on four different branches, each attributed to `native-session-resumption.test.ts` because that file was running in the worker at exit). Vitest reports it as an unhandled error and fails the shard, so the job has to be re-run, which costs a full shard (four to six minutes) on the run's critical path. > - The directory it cannot remove is one a native session leaves behind: runtime-context bundles are published under the instance root (`$PAPERCLIP_HOME/instances/<id>/runtime-context-assets/bundles/<digest>`) and every directory in them is made read-only by design (`makeDirectoriesReadOnly` in `services/native-runtime/runtime-context.ts`). A file inside a read-only directory cannot be unlinked, so the recursive removal stops with `EACCES`. Whether such a bundle is under the worker's home at exit depends on timing: suites set and restore `PAPERCLIP_HOME` for their own fixtures, and a heartbeat that is still finishing when the worker exits can publish its bundle under whichever home is current. > - The teardown is the right place to fix this: the bundle is read-only on purpose, and the test home is throwaway. On a permission error the teardown now makes every directory in the tree writable and removes it again. ## Linked Issues or Issue Description No GitHub issue exists for this. The description below follows the bug report template. What happened? A `General tests (server (n/12))` shard fails after all its test files passed: ``` Vitest caught 1 unhandled error during the test run. Error: EACCES, Permission denied: /tmp/pv-k2snZS/t/paperclip-vitest-home-qANo1F ❯ Object.rmSync node:fs:1282:18 ❯ process.<anonymous> server/src/__tests__/setup-supertest.ts:32:31 This error originated in "server/src/__tests__/native-session-resumption.test.ts" test file. Test Files 74 passed (74) Tests 3226 passed \| 1 skipped (3227) Errors 1 error ``` Seen on 2026-10-11 in the first attempt of run 38146108750 (server (11/12)), run 38150787810 (server (11/12)), run 38178832013 (server (12/12), branch `fix/windows-opencode-utf8`) and run 38179110043 (server (11/12), branch `fix/sentry-timeout-assertion-event-id`). The re-run of the same job passes every time. Expected behavior A shard whose tests all passed is green. The per-worker test home is removed at exit whatever a finishing run left in it. Steps to reproduce 1. Create a directory tree with a read-only directory inside it, the way `makeDirectoriesReadOnly` publishes a runtime-context bundle: `mkdir -p home/bundle && touch home/bundle/SKILL.md && chmod 555 home/bundle`. 2. Remove it the way the setup file did: `node -e "require('fs').rmSync('home', { recursive: true, force: true })"`. 3. The removal throws `EACCES` and leaves the tree behind. The new `removeTestHome` removes it. Paperclip version or commit `master` at `bfe7c6357`. Deployment mode CI (`pr-trusted.yml`, the general server shards on the `runs-on` fleet); the same removal runs on every local `pnpm test` in `server/`. ## What Changed - `server/src/__tests__/remove-test-home.ts` (new): `removeTestHome(home)` runs the same recursive `rmSync` as before (`force`, eight retries); on `EACCES` or `EPERM` it walks the tree, adds owner read, write and search to every directory (`lstat`, so a symlink is not followed and nothing outside the home is touched), and removes the tree again. Any other error, and a second failure, still throw. - `server/src/__tests__/setup-supertest.ts`: the exit handler calls `removeTestHome` instead of `rmSync` directly. - `server/src/__tests__/remove-test-home.test.ts` (new): a home with a runtime-context bundle whose directories and files are read-only fails the plain `rmSync` with `EACCES` (asserted, so the test documents the failure it fixes) and is removed by `removeTestHome`; an ordinary home is removed and a missing one is tolerated; a symlink out of the home is not followed, so a read-only directory it points at keeps its mode and its file. ### Review fix (second commit) - Greptile (P1): the symlink test ran on Windows without a guard, where `chmod` only toggles the read-only attribute (so the `0o555` assertion cannot hold) and a directory symlink can need elevated privileges. The test is now `it.skipIf(process.platform === "win32")`, the guard the suite's other permission tests use; the first test already guarded its `rmSync` assertion the same way. ## Verification - `vitest run src/__tests__/remove-test-home.test.ts` in `server/`: 3 tests pass (three consecutive runs on the second commit). The first one fails against a `removeTestHome` that only calls `rmSync` (it throws `EACCES` on the read-only bundle). There is no Windows job in this repo's CI, so the skip is verified by reading `os.chmod` semantics on Windows plus the guard pattern already in the suite. - `vitest run src/__tests__/env-file-policy.test.ts` in `server/`, which loads the changed setup file: passes, and the worker exits clean. `native-session-resumption.test.ts` itself could not be loaded in the workspace this was written in (the AI SDK's default OpenAI provider rejects that sandbox's empty base URL at import time, before any test runs), so the server shards on this PR's own run are the check for that file. - The three files typecheck under the server's `tsconfig.json` options (`tsc --noEmit` on a config that includes only them, since the server project excludes `src/__tests__`). - The CI failure itself is timing-dependent and was not reproduced on demand; the fix is to the teardown, which now removes the tree the failing runs left behind, as the new test shows. - First commit's CI run (38183149920): every check green on the first attempt, including all twelve server shards. ## Risks - The teardown makes directories writable only under the throwaway test home, only after a permission error, and only through `lstat` (symlinks are not followed), so it cannot reach into a developer's real `~/.paperclip` or any directory the home links to. - A home the teardown still cannot remove (an entry owned by another user, for instance) throws as before, so a real permission problem stays visible. - The underlying timing, a run still publishing a bundle while the worker exits, is unchanged; this PR makes the teardown correct for what such a run leaves behind rather than changing how runs are drained, which is a larger change to the test harness. ## Model Used - Claude (Anthropic), model id `claude-fable-5-1` (Claude Fable 5.1), extended thinking, with tool use (shell, file editing, GitHub CLI) in a Paperclip agent 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 - [ ] 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-10-12 11:25:16 -07:00
Devin Foley devinfoley Claude Fable 5.1	a96329dfa2	fix(test): stop the Sentry timeout assertion matching a random event id (#15929 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Every pull request runs the `Sentry SDK contract` workflow, whose one job installs the real `@sentry/node` outside the workspace and runs `server/src/__tests__/run-failure-sentry-real-sdk.test.ts` to prove that run-failure reports never carry provider output or credentials. > - One of its assertions checks that the captured events do not contain the provider's stderr canary `<html>504 Gateway Time-out private-timeout-credential-canary</html>`, by matching the serialized events against `/private-timeout-\|<html>\|504\|Timed out after/`. > - The bare `504` alternative also matches a Sentry event id. On pull request #15926 (a build-script change that does not touch this code) the job failed because that run's event id was `f353d184e5504ee39db611f2e60f49ff`; the re-run passed. About 0.7% of random 32-character hex ids contain `504`, and the test serializes two events, so roughly one job in seventy fails for no reason. > - This pull request narrows that alternative to `504 Gateway`, which still catches the canary with or without its HTML wrapper and cannot match a hex id. ## Linked Issues or Issue Description No GitHub issue exists for this. The description below follows the bug report template. Pre-submission checklist - [x] I have searched existing open and closed issues and this is not a duplicate. - [x] I am on the latest released version of Paperclip (or can reproduce on `master`). - [x] I have confirmed the error originates in Paperclip itself — not in my agent adapter, API provider, or local configuration. What happened? The `Sentry SDK contract` job (`Real Sentry SDK isolation`) failed on pull request #15926 at head `2d57542`, run 38178686828 attempt 1, in `run-failure-sentry-real-sdk.test.ts > captures an early OpenCode timeout without inventing a deadline or exporting provider output`: ``` AssertionError: expected '[{"exception":{"values":[{"type":"Err…' not to match /private-timeout-\|<html>\|504\|Timed out after/ ``` The serialized events contained no provider output. The match was the event id `f353d184e5504ee39db611f2e60f49ff`, which contains `504`. The pull request changes build scripts only, and the same job passed on its previous head and on the re-run of this one. Expected behavior The assertion fails only when a captured event carries the stderr canary or a `Timed out after` message, never because of the random event id Sentry assigns. Steps to reproduce 1. On `master`, run `node -e 'console.log(/private-timeout-\|<html>\|504\|Timed out after/.test(JSON.stringify([{event_id:"f353d184e5504ee39db611f2e60f49ff"}])))'`. It prints `true`. 2. Run the `Sentry SDK contract` job repeatedly; about one run in seventy draws an event id containing `504` and fails on that assertion. Paperclip version or commit `master` at `bfe7c63`. Deployment mode Other (CI, GitHub Actions) Installation method Built from source (pnpm dev / pnpm build) Agent adapter(s) involved - [x] Not adapter-specific (core bug) Database mode Not database-related Access context Unclear / not applicable Node.js version 24 (the workflow's `actions/setup-node` version) Operating system ubuntu-latest (GitHub-hosted runner) Relevant logs or output ``` ❯ src/__tests__/run-failure-sentry-real-sdk.test.ts (11 tests \| 1 failed) 2571ms × captures an early OpenCode timeout without inventing a deadline or exporting provider output 510ms AssertionError: expected '[{"exception":{"values":[{"type":"Err…' not to match /private-timeout-\|<html>\|504\|Timed out after/ "[{\"exception\":{\"values\":[{\"type\":\"Error\",\"value\":\"OpenCode execution timed out\",\"mechanism\":{\"type\":\"generic\",\"handled\":true}}]},\"event_id\":\"f353d184e5504ee39db611f2e60f49ff\", ... ``` Relevant config (if applicable) None. Additional context The assertion was added in #15789. The fixture's stderr is `<html>504 Gateway Time-out private-timeout-credential-canary</html>`, so `<html>` and `private-timeout-` already cover it; `504 Gateway` keeps a third, independent check on the status text itself. Privacy checklist - [x] I have reviewed all pasted output for PII (usernames, file paths, API keys, tokens, company names) and redacted where necessary. ## What Changed - `server/src/__tests__/run-failure-sentry-real-sdk.test.ts`: the forbidden-substring assertion matches `504 Gateway` instead of `504`. One line. ## Verification - With the real SDK installed outside the workspace the way the workflow does it (`npm install --prefix <tmp> @sentry/node@10.71.0`, `NODE_PATH` pointing at it, `PAPERCLIP_REQUIRE_SENTRY_TEST_SDK=1`), `pnpm --filter @paperclipai/server exec vitest run src/__tests__/run-failure-sentry-real-sdk.test.ts` passes 11/11 on three consecutive runs. - The failing run's payload against both patterns: the old regex matches it (`true`), the new one does not (`false`). The stderr canary with its HTML wrapper and the bare `504 Gateway Time-out` both still match the new regex. - 100,000 random 32-character hex ids: 0.73% contain `504`; none can contain `504 Gateway`. ## Risks - The assertion no longer catches a leaked `504` that appears without `Gateway` after it. The fixture's canary always carries `Gateway`, and the `<html>` and `private-timeout-` alternatives cover the same leak independently, so the test's purpose is unchanged. ## Model Used - Claude (Anthropic), model id `claude-fable-5-1` (Claude Fable 5.1), extended thinking, with tool use (shell, file editing, GitHub CLI) in a Paperclip agent 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 - [ ] 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: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-10-12 11:25:09 -07:00
Devin FoleyandClaude Fable 5.1	f8798aac1e	docs(release): align 2026.1006.0-beta.0 stable notes header with v2026.1012.0 (#16000 ) <!-- Write all pull request text in Simplified Technical English (ASD-STE100). --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The release pipeline promotes a soaked beta to stable. The stable job publishes `releases/beta/v<beta-version>.md` from `master` as the GitHub Release body, pinned at dispatch time. > - Beta `2026.1006.0-beta.0` (source `22a3ea3414e9039a538fbb0374b3cfa7fc4371eb`, 130 commits after v2026.1005.0) has soaked for more than three days. The stable version for 2026-10-12 is `v2026.1012.0`. > - The curated notes from #15388 were written at beta time. They guess `v2026.1009.0` and `2026-10-09`, which did not ship. > - A pre-dispatch audit confirmed the commit count, the PR cross-check, the migration range, the environment defaults, and the Contributors handles. Only the header, the date, the intro version, and the contributor count are stale. > - This pull request corrects those four lines before the stable dispatch, so the public release page shows the version that ships. > - The benefit is that the GitHub Release body and the canonical notes file agree with the npm version and the git tag. ## Linked Issues or Issue Description Issue type Docs: release notes. Where is the issue? `releases/beta/v2026.1006.0-beta.0.md` on `master`. What's wrong? The notes carry a guessed stable version and date from beta time: - The H1 reads `# Paperclip v2026.1009.0` and the next line reads `> Released: 2026-10-09`. No `v2026.1009.0` stable shipped. The stable that promotes this beta on 2026-10-12 resolves to `v2026.1012.0`. - The intro paragraph names `v2026.1009.0` for the same reason. - The Contributors line says 8 contributors. `git shortlog -sn v2026.1005.0..22a3ea3414e9039a538fbb0374b3cfa7fc4371eb` lists 10 authors. Excluding `github-actions[bot]` gives 9 (this count includes `dependabot[bot]`, as the v2026.916.0 notes did). Paperclip Cloud changes in the range (#15314, #15340) stay out of these notes. The notes do not cite them today, and this change does not add them. Suggested fix Change the version in the H1 and the intro paragraph to `v2026.1012.0`, change the Released line to `2026-10-12`, and change the contributor count to 9. Change nothing else. ## What Changed - Line 1: `# Paperclip v2026.1009.0` → `# Paperclip v2026.1012.0`. - Line 3: `> Released: 2026-10-09` → `> Released: 2026-10-12`. - Line 5: the intro paragraph now starts `Paperclip v2026.1012.0 carries 130 commits`. - Contributors: `from 8 contributors` → `from 9 contributors`. - No other lines changed. The 130-commit count, the cited PR numbers, the `0294`–`0305` migration range, the environment defaults, and the external handles were already correct. ## Verification - Docs only. `scripts/release.sh stable --print-version --date 2026-10-12` on `master` prints `2026.1012.0`, which matches the new header. - `git rev-list --count v2026.1005.0..22a3ea3414e9039a538fbb0374b3cfa7fc4371eb` is 130, which matches the notes. - All 89 PR numbers cited in the notes are in that range. The 40 uncited in-range PRs are 23 Dependabot bumps, one lockfile refresh, six test-only changes, five release-notes and contributor-docs changes, one CODEOWNERS change, two evals changes, one release-smoke test change, and two Paperclip Cloud changes (#15314, #15340). - Migrations `0294`–`0305` match `packages/db/src/migrations` in the range. `0298` is the only migration that updates existing rows. - Defaults were read at the beta source: `--listen-port` defaults to 43127 in `paperclip-runnerd.rs`; silent-run thresholds are 5 and 15 minutes in the sandbox runtime; remote Codex accepts `0.149.0` up to but excluding `0.161.0` in `codex-runtime-compatibility.ts`; pins are Codex `0.160.0`, Claude Agent SDK `0.3.286`, OpenCode `1.18.34`; Sonnet 5.5 needs Claude Code `2.1.284` or later. - `git shortlog -sn` over the range gives 9 contributors excluding `github-actions[bot]`. The external handles are `@baozdemir`, `@valentinpalkovic`, and `@abderbejaoui`, which the notes already list. - `git diff --stat` shows one file, 4 insertions, 4 deletions. ## Risks Low. Documentation only. This must merge before the stable dispatch, because the stable job pins the `master` revision of this file at dispatch time. ## Model Used Anthropic Claude Fable 5.1 (`claude-fable-5-1`) via Claude Code, with tool use 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 (docs only; no tests apply) - [x] I have added or updated tests where applicable (none apply) - [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 (running) - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups (running) - [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 Fable 5.1 <noreply@anthropic.com> canary/v2026.1012.0-canary.10	2026-10-12 11:03:49 -07:00
Tiangao zocomputer commitperclip[bot]	2145925f71	fix: use Hermes adapter API URL env in prompt (#9425 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The Hermes adapter builds the command environment and renders the prompt that tells Hermes how to call back into Paperclip. > - Adapter configuration can provide `PAPERCLIP_API_URL` through `config.env`, which is often the most precise API base for the spawned worker. > - The current prompt rendering path does not read that adapter env value when deciding which Paperclip API base to show. > - This can leave Hermes with prompt instructions that point at a less appropriate process-level or public URL, even though the adapter env contains the intended API base. > - This pull request makes prompt rendering honor the adapter env value before falling back to broader process defaults. > - The benefit is a more consistent Hermes prompt without changing command execution behavior. ## Linked Issues or Issue Description Adapter: Hermes Agent or provider Hermes local adapter. Why this adapter is useful The Hermes adapter lets Paperclip run Hermes-backed agents while preserving Paperclip run context and callback instructions. How the agent is invoked Paperclip spawns the configured Hermes command and passes a rendered prompt plus adapter-provided environment variables. What happened? When `PAPERCLIP_API_URL` is supplied through adapter env, the Hermes subprocess receives it, but the prompt can still render its API base from a process-level fallback instead of that configured adapter env value. Expected behavior If an explicit `paperclipApiUrl` option is not configured, the prompt should prefer `config.env.PAPERCLIP_API_URL` when present, then fall back to the existing defaults. Related context: supersedes NousResearch/hermes-paperclip-adapter#118 for Paperclip's bundled Hermes adapter. ## What Changed - Added a small env-value resolver for raw string values and `{ value: string }` wrappers. - Builds a prompt-specific config that uses `config.env.PAPERCLIP_API_URL` when `paperclipApiUrl` is not explicitly set. - Added a focused command-resolution test that verifies the rendered prompt API base uses the adapter env URL instead of the process fallback. ## Verification - `pnpm --filter @paperclipai/hermes-paperclip-adapter test:command-resolution` - `pnpm --filter @paperclipai/hermes-paperclip-adapter typecheck` - `pnpm --filter @paperclipai/hermes-paperclip-adapter build` ## Risks Low risk. This only affects prompt rendering for Hermes adapter runs where `paperclipApiUrl` is unset and `config.env.PAPERCLIP_API_URL` is present. Explicit `paperclipApiUrl` values keep precedence, and existing fallback behavior remains in place when the env value is absent. ## Model Used OpenAI Codex, GPT-5.5, tool-enabled coding session with local shell, Git, and GitHub CLI 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: zocomputer <help@zocomputer.com> Co-authored-by: commitperclip[bot] <284812584+commitperclip[bot]@users.noreply.github.com>	2026-10-12 10:39:23 -07:00
Devin Foley	4f399cec9f	fix(docker): skip the full-tree ownership walk on routine boots (#15992 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Docker image keeps all instance state under `PAPERCLIP_HOME`, and deployments mount a volume there > - Before it drops privileges, the entrypoint makes sure that the `node` user owns the home (#10530) > - The ownership probe is a first-mismatch `find` over the whole tree. When ownership is correct, `-quit` never fires, so every boot stats every file on the volume > - On homes with many agent worktrees and `node_modules` trees, this walk takes minutes before Node starts. That is close to common 300s healthcheck windows > - This pull request keeps a cheap shallow probe on every boot. It runs the full-tree probe only once per volume and node UID/GID, and records the result in a marker file > - The benefit is that routine boots no longer scale with the file count, and the original root-owned-volume fix stays in place ## Linked Issues or Issue Description Refs #10431 (the open follow-up about the remaining cost of the ownership walk). Related: #10530 (the change that added the full-tree probe). What happened? On a hosted multi-instance deployment, we measured the time from container start to the first app log line. Instances with many files on the volume (agent worktrees with `node_modules`) took about 190-235s. Small instances took 5-22s. One 30 GB volume with few files took 24s, so the cost follows the file count, not the volume size. Almost all of this time is the `find "$home_dir" $ ! -user node -o ! -group node $ -print -quit` walk in `scripts/docker-entrypoint.sh`. When ownership is already correct, `-quit` never fires, so the walk stats every inode on every boot. Expected behavior When ownership is already correct, the entrypoint pre-start phase is short and does not depend on the number of files in `PAPERCLIP_HOME`. A fresh root-owned volume, a UID/GID remap, and an upgrade from an older image are still repaired before the privilege drop. Steps to reproduce 1. Run the image with a volume on `/paperclip` that holds a few hundred thousand files, all owned by `node:node`. 2. Restart the container. 3. Compare the container start time with the first server log line. The gap grows with the file count, even though no `chown` runs. Paperclip version or commit `master` at `a9830414c7` Deployment mode Docker production image (any platform that mounts a volume on `PAPERCLIP_HOME`) ## What Changed - `scripts/docker-entrypoint.sh`: the ownership probe is now tiered. - Every boot runs a shallow probe (`find -maxdepth 3`) over the home and its first three levels. A fresh root-owned mount and a UID/GID remap both change the owner of the home directory, so this probe catches them. - The full-tree probe runs only when `PAPERCLIP_HOME/.paperclip-ownership-verified` is missing or records a different node UID/GID (format `v1 <uid>:<gid>`). This catches deep mismatches, including the first boot after an upgrade from an older image. - Any mismatch repairs the whole tree with `chown -R node:node`, as before. After a clean probe or a repair, the entrypoint writes the marker as the `node` user (through `gosu`), so the marker never trips the shallow probe. A failed marker write is ignored: the only cost is a full probe on the next boot. If `find` exits non-zero without a mismatch (for example, an I/O error), the walk is incomplete, so the entrypoint does not write the marker and the next boot probes again. - `scripts/docker-entrypoint.sh`: timestamped log lines at entrypoint start, around the full probe and the repair (with durations), and right before the `exec` of the server. You can now measure the pre-start phase from the container log. - `server/src/__tests__/docker-entrypoint.test.ts`: the `find` stub now tells the shallow probe from the full probe. New tests cover each path (see Verification). - `doc/DOCKER.md`: documents the marker, how to force a full check, and the new log lines. ## Verification - `cd server && npx vitest run src/__tests__/docker-entrypoint.test.ts src/__tests__/container-init-reaping.test.ts src/__tests__/docker-build-stamp.test.ts`: 40 passed. New cases: - correct ownership + current marker → shallow probe only, no full walk, no `chown` - current marker + deep-only mismatch → full walk skipped (this is the documented trade-off) - no marker (upgrade) → one full walk, no `chown`, marker written as `v1 1000:1000` - no marker + deep mismatch → full walk finds it, `chown -R`, marker written - root-owned top level with a current marker → `chown -R` without a full walk - full walk fails without a mismatch → no `chown`, no marker, retry logged - marker for another UID/GID → full walk runs again, marker rewritten as `v1 1001:1001` - timestamped `starting`, `ownership repair finished in Ns`, and `starting app as node` lines, in order, before the command runs - The new tests fail against the old script. The 11 existing tests pass unchanged. - `cd server && npx tsc --noEmit`: passes. - `shellcheck -s sh scripts/docker-entrypoint.sh`: clean. `dash -n`: syntax OK. - Manual run with the real `find` (BSD find, script run under `dash`) against a 200k-file tree. Only `id`/`usermod`/`groupmod`/`chown`/`gosu` were stubbed, and `node` was mapped to the local user and group: - boot 1, no marker, one deep group mismatch → full probe, `chown -R`, marker written - boot 2, marker present → no full probe, no `chown` - boot 3, no marker, clean tree → full probe, no `chown`, marker written - boot 4, marker present, clean → no full probe, no `chown` - boot 5, top-level group mismatch with marker → `chown -R` - I did not build the image or measure boot time in a container. Docker was not available on the machine I used. On a warm local disk the full walk is sub-second, so the local timings say nothing about cold network block storage. ## Risks - Once the marker is current, a mismatch deeper than three levels is not detected automatically. Examples: files written as root by `docker exec` or a restore run as root, after the first verified boot. Before this change, those files were repaired on the next boot. The workaround is in `doc/DOCKER.md`: delete the marker and restart. A remap, a fresh volume, and a root-owned top level are still detected on every boot. - On the first boot after an upgrade, each existing volume pays one full walk (the same cost as today). Later boots skip it. - The marker is a new dotfile in `PAPERCLIP_HOME`. Backups and copies that include the home carry it along. This is safe, because the marker records the UID/GID that it verified, and a different UID/GID forces a new full probe. - The non-root path (restricted PodSecurity, OpenShift) does not change, apart from two new stdout log lines. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`, 1M context) via Claude Code, with tool use (shell, file editing). Default reasoning mode. ## 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	2026-10-12 10:22:43 -07:00
DottaandPaperclip	a2ac5c2715	refactor(chat): isolate Telegram, Slack, GitHub and Discord workflows (#15976 ) ## Thinking Path > - Paperclip manages AI agents and their work. > - Chat channels connect that work to external conversations. > - The shared chat service still contains provider-specific workflows. > - Those workflows are hard to inspect in a 34,000-line file. > - This stack extracts Telegram, Slack, GitHub and Discord workflows into their channel folders. > - Shared authorization and service lifetime remain explicit. ## Linked Issues or Issue Description Refs #15823, #15834, #15836, #15844 and #15845. Root of the second behavior-preserving channel-folder refactor stack. The dependent PRs #15979, #15981, #15985 and #15987 have merged into this branch; this PR lands all five extractions on master. ## What Changed - Move Telegram maintenance and subscription repair into `chat-channels/telegram/maintenance.ts`. - Move Slack session stopping and task starts into `chat-channels/slack/session-stop.ts` and `task-start.ts`. - Move GitHub webhook intake and recovery into `chat-channels/github/webhook-ingress.ts`. - Move Discord command registration and handling into `chat-channels/discord/commands.ts`. - Share type-only runtime records while preserving shared authorization, transactions, live lease checks and worker ownership. - Reduce the original service from 34,603 to 29,897 lines, removing 4,706 lines (13.6%). ## Verification - All 205 selected integration cases passed before and after their respective extractions: Telegram 41, Slack session stop 2 multi-step scenarios, GitHub 84, Slack task start 25 and Discord 53. Each dependent PR records its focused reproduction command. - Server typecheck, module boundaries and whitespace checks passed. - Per-slice syntax comparisons passed for moved declarations and remaining service statements, allowing only the documented live callback substitutions. - Tests exercise the public service with disposable databases and fixture provider transports. They do not claim live third-party execution. - Cumulative workspace typecheck and build passed on the final stack. - Current-head CI passed on the combined stack commit `d5b37dbe512e3e199932b6608cdc17639eda555a`; Greptile is 5/5 with no unresolved threads. - The [original serialized shard](https://github.com/paperclipai/paperclip/actions/runs/38266518817/job/114870022249) timed out in unchanged `adapter-auth-signal-routes.test.ts`. The exact case passed locally without changes, and the [single job retry](https://github.com/paperclipai/paperclip/actions/runs/38266518817/job/114874019933) passed. The original timeout remains recorded. Reproduce the original Telegram slice’s focused suite: ```sh pnpm exec vitest run server/src/__tests__/chat-channels.integration.test.ts -t 'Telegram durable private draft Stop\|Telegram maintenance\|Telegram webhook\|Telegram.(pause\|remove)\|Telegram.commands' ``` - Cumulative local `pnpm test:run` exited 1: the first server group had 18,770 passed, 105 skipped, and one timeout in unchanged `server/src/services/workspace-git-snapshot-streaming.test.ts:56` (300,000 ms on macOS). The fail-fast runner did not reach its later workspace and serialized groups. An unchanged isolated rerun passed using the existing timeout; this does not turn the original full run green. The test and its Git utility code are outside this refactor; all current-head CI jobs passed. - Reproduce that diagnostic alone: `pnpm exec vitest run server/src/services/workspace-git-snapshot-streaming.test.ts`. ## Risks - Credential lease ownership and provider-confirmation ordering must remain unchanged. Existing rotation, lease-loss, recovery and durable Stop cases pass. - The channel factories create no workers or timers and preserve live runtime, shutdown and gateway-ownership reads. ## Model Used OpenAI Codex, GPT-6 family, with reasoning and repository tools. The exact runtime model ID and context-window size are not exposed in this session. No separate agent was 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 - [ ] 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-12 12:03:23 -05:00
Dotta	a9830414c7	Preserve repository dependencies when importing GitHub skills (#15731 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its Skills library imports reusable instructions from GitHub. > - Some skills depend on shared files and sibling skills outside their folders. > - Directory-only imports lose those dependencies. > - This pull request keeps repository files together and lets users select which skills appear in the library. > - Agents receive the original files and paths through the existing skill delivery system. ## Linked Issues or Issue Description Refs #14713. Related: #13656. Current behavior GitHub imports copy independent skill directories. Shared scripts, policies, helper skills, and credit files can be omitted. One shared-file error can block every skill. Proposed behavior New imports keep repository files together at the scanned commit. Show all skills with their folders and select every skill by default. Collapse individual package files. Omit unsupported or oversized files with a warning. Import available content without repair choices or an extra confirmation. Keep warnings on the saved source. Reason and benefit Skills can read their shared repository files after Paperclip delivers them to an agent. Original instructions stay unchanged. Users can inspect included files and understand omissions before and after import. ## What Changed - Store immutable company-scoped repository snapshots and associate them with skill versions. Regenerate the migration after merging master. - Preserve original bytes, binary encoding, and executable modes. Shared-file changes version each usable selected skill. Pinned versions retain their original files. - Deliver a discovery wrapper with the original tree under `.paperclip-repository/`. Preserve invocation policy when present. Fork and create-from-existing retain repository files. - Keep repository files together for new UI imports. Show every skill, select all by default, and collapse package files. Remove the packaging-mode menu. Keep the mobile import footer visible. - Warn about symlinks, submodules, oversized files, missing references, and invalid optional manifests. A malformed skill remains selected with a Needs setup warning. Usable skills still publish, and its original file remains repository support content. Source warnings persist through refresh. Unsafe execution and secret-disclosure findings omit the affected files before snapshot publication. - Expose saved repository files in the installed skill viewer, including binary encoding and executable flags. Reads use the immutable company-scoped snapshot; relative instruction links resolve from their original repository directory. - Audit delivered inventories and derive trust from all repository files. Accept evaluation prose while retaining dynamic-execution findings. Read blobs in one bounded Git batch and check budgets before reading support files. Imports never execute setup commands. - Add scanner, database, delivery, UI, and browser regressions. Update Storybooks, screenshots, and documentation. ## Verification - 69 focused scanner, Git snapshot, delivery, and PostgreSQL lifecycle tests passed. They cover partial imports, warning persistence, missing references, binary files, executable modes, copies, pinned versions, cancellation, company isolation, and batched Git reads. - 110 import, skill-detail, selection-tree, saved-file link, and Markdown renderer tests passed. A file-switch regression failed before the resolver fix and passed afterward. Browser walkthroughs cover the all-selected open tree, repository preview, non-blocking warnings, missing references, setup problems, warning persistence, and mobile layout. - Full workspace typecheck and build passed. Runner E2E TypeScript checks and design-token gates passed. The full serial local suite was attempted and stopped after over an hour. The existing 40,000-file Git streaming stress test failed after 303 seconds on macOS; the broad local suite is not counted as passed. All 55 applicable PR checks passed on the final commit, including the full sharded CI suite. Two optional Storybook workflows were skipped; the five local Storybook walkthroughs passed. - On October 12, live campaigns imported the private Poteto repository through the production GitHub Sources UI, selected architect and bro, and invoked them with native Codex on local and Daytona. The source connection was disabled before invocation. Independent filesystem inspections matched every supported Git blob, size, and executable mode. Both tasks completed and cleanup passed. Campaigns: `local-2026-10-12T15-07-39-504Z` (both environments), `local-2026-10-12T16-08-39-682Z` (local), and `local-2026-10-12T16-03-33-938Z` (Daytona). Each of the two selected skills received all 234 supported repository files. Later changes only affect the installed-file viewer and documentation. This qualifies skill delivery and instruction reads, not every Poteto workflow or adapter. - A manual source-checkout test drive imported a synthetic private GitHub repository with a symlink, an oversized file, a missing reference, and malformed skill metadata. Available skills published with their shared checklist. The walkthrough found duplicate warning text after import; the final UI fix removes that duplicate. The file viewer exposes saved repository dependencies and resolves authored relative links without changing the instructions. A follow-up live refresh omitted unsafe helper files with warnings, preserved every safe file byte, and survived a server restart. Screenshots below use the production UI with Storybook fixtures. They do not replace the live GitHub and runtime checks. <details> <summary>All skills visible and selected by default</summary> ![Default repository import](https://github.com/paperclipai/paperclip/blob/codex/skill-repository-packages/docs/pr-screenshots/pr-15731/repository-import.png?raw=true) </details> <details> <summary>Import stays available with warnings</summary> ![Import warnings](https://github.com/paperclipai/paperclip/blob/codex/skill-repository-packages/docs/pr-screenshots/pr-15731/repository-warning-details.png?raw=true) </details> <details> <summary>Repository file inspector</summary> ![Repository files](https://github.com/paperclipai/paperclip/blob/codex/skill-repository-packages/docs/pr-screenshots/pr-15731/repository-files.png?raw=true) </details> <details> <summary>Mobile import</summary> ![Mobile import](https://github.com/paperclipai/paperclip/blob/codex/skill-repository-packages/docs/pr-screenshots/pr-15731/repository-mobile.png?raw=true) </details> ## Risks - Each selected skill carries a repository copy in the runtime. The database stores each snapshot once. Runtime transfer and storage increase with the number of assigned skills. - Runtime budgets remain: 9,990 repository entries, 1 MiB per file, and 61 MiB total. File omissions are recorded as warnings. Source-access or download failures retain installed versions. - Import success does not prove that every skill can run. Environment dependencies, credentials, delegation tools, and schedules still need configuration. Imported setup scripts are not executed. - Live runtime coverage is native Codex on local and Daytona. Other adapters use the shared delivery path but were not exercised in these campaigns. The roadmap marks Skills Manager as shipped. This extends the existing importer. Related pull requests were checked. ## Model Used OpenAI Codex, based on GPT-6, with repository inspection, code execution, automated tests, and browser tools. The exact deployment identifier and context-window size were 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 - [ ] 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 canary/v2026.1012.0-canary.8	2026-10-12 11:30:20 -05:00
DottaandPaperclip	ce08872dfb	refactor(heartbeat): extract instruction working-copy lifecycle (#15984 ) ## Thinking Path > - Paperclip runs agent tasks and preserves their managed agent files. > - Heartbeat must prepare a private copy, collect stopped-provider edits, and retain ownership during warm-session handoff. > - That lifecycle is spread across preparation, adapter callbacks, and cleanup. > - A per-run controller can own the copy and receipt while the executor retains teardown ordering. > - This PR moves that coordination into a dedicated module. > - Live getters preserve updated state and partially acquired resources. ## Linked Issues or Issue Description What existing behavior does this improve? Maintenance of heartbeat instruction preparation. This is the second and final PR in this batch, originally stacked on #15980. That dependency is now merged; this PR is rebased onto its squash merge with an identical patch and identical touched-file contents. Related-PR search found no duplicate extraction. Current behavior After #15980, `heartbeat.ts` has 4,215 lines and 173,657 bytes. It coordinates instruction-copy preparation, save receipts, warm handoffs, and deferred cleanup inline. Proposed behavior `heartbeat/instruction-working-copy.ts` owns the per-run lifecycle in 233 lines. `heartbeat.ts` becomes 4,055 lines and 162,520 bytes. The executor retains the outer release order, unavailable-copy reporting, and environment/service cleanup policy. Reason and benefit The copy, save receipt, and warm ownership are readable together. The remaining executor names preparation and dispatch phases without obscuring teardown decisions. Breaking changes None intended. All 140 named public heartbeat exports remain unchanged. ## What Changed - Extract copy preparation, save/checkpoint callbacks, warm reservation/adoption, prompt guidance, and the deferred-release closure. - Read the executor's current run row through a callback; expose current copies, receipts, and acquired cleanup handles through live getters. - Keep cleanup handles available after preparation failure, and preserve release-before-retry on invalidated warm reuse. - Add four public-path characterization tests with real disposable PostgreSQL and files, plus four direct boundary tests. - Add isolated browser acceptance with a real process that edits instructions, completes its task, and reads the saved bytes on its next task. - Document the boundary and opt-in acceptance command. ## Verification - Before extraction: four new public-path tests pass on the original implementation, as do 108 existing instruction-copy/directory/native-cleanup tests. The two-task browser journey also passes on the baseline server. - After extraction: all 112 baseline tests pass; all four new boundary tests pass; 12 selected native-session ownership/retirement cases pass (the other 670 cases were outside this focused selection). - Browser acceptance: the fresh extracted-code server passes the full two-task journey (25.9 seconds): real child-process edits, saved/unchanged receipts, canonical bytes through the agent-file API, next-task restore, completed task UI, and copy cleanup. - `pnpm -r typecheck`, final server typecheck, and `pnpm build` pass. Module-boundary and public-export checks pass. - Normalized syntax comparison confirms all moved bodies and the reconstructed executor match the base, accounting explicitly for live run getters and delegation. - Final rebased head: `a08872c97e587a21ffc0fc6b78f34b81e484e7b0`. Combined entry-point and boundary regressions pass again (12/12); fresh Greptile review is 5/5 with no findings. All 55 current-head checks pass (two configured skips), including the hosted full-suite tests, build, typecheck, and all eight browser shards. There are no open review threads. ## Risks - Acquisition can succeed before preparation throws. Boundary tests verify that both the reservation and a transferred copy remain visible to the cleanup owner. - Callbacks can replace copy/save state during execution. Public tests verify saved receipts; direct tests verify the current run row, warm checkpoint receipt, and permission-root preservation. - Missing edit authorization and cleanup failure must remain nonfatal. Characterization tests revoke actual membership after dispatch admission and inject a cleanup error while preserving the saved result. - The browser uses a test-launcher-only instruction-capable wrapper around the real process adapter. Production adapter capabilities are unchanged. No live provider calls are made; native warm ownership is covered by focused module and native-session tests rather than a live provider browser run. ## Model Used OpenAI Codex, based on GPT-6, assisted with reasoning, code edits, tool execution, and verification. The exact deployment 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-12 10:52:32 -05:00
DottaandPaperclip	1e0cfcb4fc	test: retire redundant suites and consolidate owner coverage (#15978 ) Retire duplicate ACPX and Codex proof after migrating unique assertions to their behavioral owners. Consolidate repeated fixtures and exact case matrices while preserving lifecycle, protocol, company, credential, approval, and ordering contracts. Remove the unused runtime-controls compatibility path and document test ownership and preservation evidence. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-12 10:44:02 -05:00
DottaandPaperclip	94e4218310	refactor(heartbeat): extract runtime service coordination (#15980 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Heartbeat runs start workspace services and receive service reports from adapters. > - Service context updates and readiness notices are spread through the executor. > - These steps share a clear responsibility, while process and lease ownership already live elsewhere. > - This pull request puts service coordination in one module. > - The executor retains the same dispatch and cleanup order. ## Linked Issues or Issue Description What existing behavior does this improve? Maintenance of heartbeat execution. This is the first of two final focused extractions after #15973. Related #15653 changes runtime callback origins; this PR preserves that policy. Current behavior `heartbeat.ts` has 4,372 lines and 178,459 bytes. It validates service intents, starts services, persists adapter reports and primary URLs, and posts readiness notices inline. Proposed behavior `heartbeat/runtime-services.ts` owns those steps in 212 lines. `heartbeat.ts` becomes 4,215 lines and 173,657 bytes. Process registries and leases stay in `workspace-runtime.ts`. The executor still releases services in its original cleanup path. Reason and benefit Service coordination has named preparation and result phases. The execution path is easier to read without changing service lifetime or moving cleanup policy. Breaking changes None intended. All 140 named public heartbeat exports remain available, including `postWorkspaceReadyComment`. ## What Changed - Move service-intent validation, startup, adapter-result persistence, and readiness notices into one module. - Preserve mutable run context, primary URL selection, notice error handling, and release ordering. - Add four public-path tests using disposable PostgreSQL, real HTTP service processes, and a fixture adapter. - Extend browser recovery acceptance to fetch the actual service URL, check the readiness notice, and verify listener cleanup. - Update the module map and acceptance instructions. ## Verification - Before extraction: all five tests pass, including the four new characterization cases and existing notice formatting test. - After extraction: all 17 tests pass across service coordination, notice formatting, output recording, and runtime authorization. - Structural comparison confirms that all moved bodies and the reconstructed executor match the baseline. Module boundary checks pass. - `pnpm -r typecheck` and `pnpm build` pass. - Extended isolated browser acceptance: 2/2 pass (3.7 minutes), covering actual service readiness, recovery, bounded failure, and cleanup. At `8e33e2032de681082f128470eb8ab0711b382afe`, all 55 current-head checks pass (two configured skips), including hosted full-suite tests. Greptile is 5/5 with no findings or review threads. ## Risks - Service context must be persisted before adapter dispatch and before run completion. The tests inspect both phases and preserve the first service URL when adapter reports arrive. - Notice failures must remain nonfatal. The public-path test checks both startup and result notices. - Shared services must survive run cleanup; ephemeral services must stop after success or failure. Tests use actual processes and HTTP requests. - The fixture supplies UUID service report IDs, as required by the database. The existing generated-ID fallback for reports without IDs is outside this extraction. - Test adapters and services are local fixtures; these tests make no live provider calls. ## Model Used OpenAI Codex, based on GPT-6, assisted with reasoning, code edits, tool execution, and verification. The exact deployment 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-12 10:40:42 -05:00
DottaandPaperclip	914b70572c	refactor(heartbeat): extract execution configuration (#15973 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Heartbeat turns task, agent, environment, and account settings into an executable run. > - The executor still assembles scoped credentials and skill configuration inline between environment selection and session preparation. > - That phase has a clear input/output boundary, but credential acquisition must remain visible to cleanup even when later setup fails. > - This pull request extracts configuration assembly and immediately notifies the executor of acquired resources and redaction state. > - The executor retains admission, dispatch, and cleanup, with the same statement ordering and explicit busy-account deferral. ## Linked Issues or Issue Description What existing behavior does this improve? Maintenance of heartbeat execution. This PR follows #15969 and #15966, both now merged. The branch is rebased onto `master`; `git range-diff` confirms that the extraction patch is unchanged. Current behavior `heartbeat.ts` has 4,561 lines and 188,950 bytes. Configuration assembly mixes workspace overrides, secrets, managed AI preparation, and skill delivery into the executor. Proposed behavior `execution-configuration.ts` owns this preparation phase in 269 lines and 16,204 bytes. The executor calls it between environment and session preparation and retains immediate cleanup ownership. `heartbeat.ts` becomes 4,372 lines and 178,459 bytes. Reason and benefit The execution path exposes another named phase, with tests that exercise its effective configuration, resource lifetime, failure diagnostics, and busy-account result through public heartbeat dispatch. Related work: #11827 changes pre-dispatch secret refresh and #15355 changes GitHub delegation; this extraction preserves current policies. Breaking changes None intended. Public exports remain available, and the original helpers keep their modules. ## What Changed - Move configuration merging, scoped secret resolution, managed AI acquisition, runtime skills, connector instructions, and managed identity preparation into one typed module. - Notify the executor immediately when failure-redaction values, managed credentials, and identity redaction become available. Returning resources only after all preparation succeeds would lose cleanup on partial failure. - Preserve the live failure-secret getter for later runtime environment changes. Return an explicit deferred result for busy accounts. - Add four real-database characterization tests through `heartbeat.wakeup`, using actual credential files and cleanup with a fixture adapter. - Update the developer module map. ## Verification - Before extraction: all 45 tests pass across the new public-path tests and existing project-environment tests. - After extraction: 47 tests pass across execution configuration, project environment, and runtime skills. No skips. - Two additional real-process managed identity tests pass; nine unrelated cases are deliberately filtered out. - `pnpm -r typecheck` and `pnpm build` pass. - Normalized syntax comparison confirms the moved body and reconstructed executor match after accounting for immediate ownership callbacks and the explicit prepared/deferred result. - Isolated browser acceptance: 2/2 pass (3.9 minutes). A real process worker completes after Git recovery, with persisted stdout and matching final output byte counts. Persistent failures stop after three attempts. Both outcomes survive reload. The disposable server was shut down after verification. - All eleven new public-path characterization cases across the three-PR stack pass together on the final commit. - All 140 named public exports from the batch baseline remain available. - CI initially failed the legacy-continuation message browser case: periodic recovery escalated the issue, then queue admission cancelled the run with `execution_reconciliation_required` before configuration preparation. The unchanged predecessor shard passes, and the exact case passes locally (5 seconds in the browser). The original failing case passed on its single rerun (8.2 seconds), but GitHub then shut down the runner during a different test (`The runner has received a shutdown signal`). The separate infrastructure restart completed: 24 browser cases passed, with two existing optional cases skipped. Assertions and timeouts are unchanged. - Greptile: 5/5 on `27ab7e3df64c157ba1f00c5757db812ff7a4e5aa`, with no actionable findings. Hosted full-suite CI passes on this exact commit: all 54 check runs and the additional commit status are successful. - Merge preparation: all eleven characterization tests pass after rebasing onto `master`. Fresh full CI passes for `1758673f87eaa76a8b2c520eac4b631ada5d9ba1`: 55 successful checks and two optional Storybook skips, including all eight browser shards, typecheck, tests, and build. Greptile is 5/5 on this exact commit with zero review threads. All heartbeat source, tests, documentation, and browser assertions are identical to the previously reviewed final stack. ## Risks - A failure after AI acquisition must still remove the disposable credential home. The new public-path failure test proves actual filesystem cleanup and diagnostic redaction before the external reporting sink. - The baseline exposed an existing gap: arbitrary exception text in the local `run.error` field can contain a credential even though the failure reporter redacts it. This behavior is unchanged and merits a separate fix; the test does not claim the local error field is sanitized. - Account-busy deferral must return without dispatch while retaining its scheduled retry. The new test checks the durable run states. - Browser acceptance uses a real process fixture and disposable data, without live provider calls. ## Model Used OpenAI Codex, based on GPT-6, assisted with reasoning, code edits, tool execution, and verification. The exact deployment 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-12 10:01:00 -05:00

1 2 3 4 5 ...