forked from farhoodlabs/paperclip
e691d30d12b44da5bd405a2d87fafbbb1bb6549e
2498 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dotta
|
e691d30d12 | fix(plugin): harden kubernetes sandbox orchestration | ||
|
Dotta
|
163e3ca1a5 | feat(plugin): add kubernetes sandbox provider | ||
 Chris Farhood
|
55d6c5bfa4 | Merge upstream/master into dev (13 commits — includes #5922, #5938, blocked inbox, recovery actions) | ||
|
Chris Farhood
|
b6b81f2f06 | Merge updated feat/plugin-acquire-lease-agent-id into dev (adds tests) | ||
|
Chris Farhood
|
4c4eeaba2b |
test: cover agentId threading on plugin lease RPCs and call sites
Adds focused tests for every code path the agentId addition touches:
- environment-runtime.test.ts (4 new tests):
- plugin-driver acquireLease forwards agentId in RPC payload when present
- plugin-driver acquireLease omits agentId from RPC payload when null
- sandbox-provider acquireLease forwards agentId when present
- sandbox-provider resumeLease forwards agentId when reuseLease=true matches
- seedEnvironment helper now exposes the seeded agentId
- environment-run-orchestrator.test.ts (2 new tests):
- acquireForRun threads agentId through to runtime.acquireRunLease
- logActivity records the same agentId on environment.lease_acquired
- new vi.hoisted mocks for environmentService.getById + ensureLocalEnvironment
- agent-test-environment-routes.test.ts (1 new assertion):
- ad-hoc operator test-environment probe calls acquireRunLease with
agentId: null and heartbeatRunId: null (no agent context)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Dotta
|
f4bed4a70f |
Release changelog v2026.513.0 (#5944)
## Summary - Add `releases/v2026.513.0.md` covering the stable release range `v2026.512.0..origin/master` (6 PRs). - Includes one new DB migration (`0084_issue_recovery_actions`) under the Upgrade Guide. - No breaking changes detected; all PRs are core-maintainer commits so the Contributors section is omitted. ## Highlights captured - Source-scoped recovery actions ([#5599](https://github.com/paperclipai/paperclip/pull/5599)) - Blocked Inbox attention view ([#5603](https://github.com/paperclipai/paperclip/pull/5603)) - Local plugin development workflow ([#5821](https://github.com/paperclipai/paperclip/pull/5821)) ## Test plan - [ ] Reviewer confirms the highlight/improvement/fix categorization matches release intent - [ ] Reviewer confirms `0084_issue_recovery_actions` upgrade note is accurate - [ ] Reviewer signs off on `releases/v2026.513.0.md` for the stable release cut Generated under [PAP-9378](/PAP/issues/PAP-9378) via the `release-changelog` skill. Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
4142559c37 |
[codex] Add blocked inbox attention view (#5603)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies through company-scoped issues, comments, approvals, and execution workspaces. > - Operators need the Inbox to show not only active work, but also blocked work that may need human or agent attention. > - The existing inbox experience did not have a dedicated blocked-work surface, so blocked tasks were harder to triage and resume deliberately. > - Backend consumers also needed a compact attention signal that distinguishes actionable blockers from covered or waiting blocker states. > - This pull request adds a Blocked Inbox tab backed by issue blocker-attention metadata, shared validators, and UI helpers. > - The benefit is a clearer triage path for stalled or blocked Paperclip work without exposing external wait internals in the operator-facing UI. ## What Changed - Added shared issue blocker-attention types, validators, and exports for the API/UI contract. - Added backend blocker-attention computation and issue route support for blocked inbox data. - Added the Blocked Inbox tab, blocked reason chips, filtering/search UI, responsive layouts, and Storybook stories. - Updated inbox helpers and page behavior so toolbar controls only appear where they apply. - Added coverage for shared validators, server blocker-attention behavior, blocked inbox UI helpers/components, and the Inbox page. - Added a screenshot helper script for the blocked inbox Storybook stories. - Addressed Greptile feedback by making urgency sorting deterministic for null stop times, avoiding full blocked-inbox list enrichment for counts, and hardening the screenshot helper. ## Verification - Rebased the branch cleanly onto `public-gh/master`. - Confirmed the diff does not include `pnpm-lock.yaml`. - Confirmed the diff does not include database migration files. - Ran `pnpm exec vitest run packages/shared/src/validators/issue.test.ts server/src/__tests__/issue-blocker-attention.test.ts ui/src/components/BlockedInboxView.test.tsx ui/src/components/BlockedReasonChip.test.tsx ui/src/lib/blockedInbox.test.ts ui/src/lib/inbox.test.ts ui/src/pages/Inbox.test.tsx`. - Ran `pnpm --filter @paperclipai/shared typecheck && pnpm --filter @paperclipai/server typecheck && pnpm --filter @paperclipai/ui typecheck`. - Checked `ROADMAP.md`; this is scoped inbox/operator triage work and does not duplicate a listed roadmap feature. - Greptile Review is green on the latest head and all four Greptile review threads are resolved. - GitHub PR checks are green on the latest head: policy, security/snyk, e2e, verify, Canary Dry Run, Greptile Review, and serialized server suites 1/4 through 4/4. ## Risks - Medium review surface because this touches the shared issue contract, server issue services, and the Inbox UI together. - Blocker-attention classification may need product tuning after operators use it on real blocked queues. - UI screenshots were not attached in this PR-opening pass; the branch includes `scripts/screenshot-blocked-inbox.mjs` and Storybook stories for visual capture. > 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, GPT-5-based coding agent with shell, git, GitHub CLI, GitHub connector, and Paperclip API tool use. Reasoning mode: medium. Context window: not exposed by the runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
d1a8c873b2 |
fix(remote-sandbox): harden host workspace resumes (#5922)
## Thinking Path > - Paperclip orchestrates AI agents through a control plane while adapters execute work in local, remote, or sandboxed runtimes. > - Remote sandbox execution depends on a strict host-versus-remote workspace boundary: the host prepares/restores files, while the adapter command runs inside the sandbox cwd. > - Jannes' PR #5823 identified host-side failure modes that were not covered by replacement PR #5822. > - Persisting a remote pod cwd in session params could poison the next host heartbeat resume and make Paperclip inspect or upload system temp roots. > - Plugin sandbox providers also need a narrow way to receive model-provider API keys without exposing the full server environment to every plugin worker. > - This pull request ports the host-side fixes from #5823 in the current codebase style, with focused regression coverage. > - The benefit is safer remote sandbox resumes and plugin worker environment handling without broadening core plugin privileges. ## What Changed - Persist host workspace cwd, not remote sandbox cwd, in `claude_local` session params while retaining remote execution identity metadata. - Reject saved session cwds that point at system roots before heartbeat falls back to agent home workspace. - Skip sockets, FIFOs, devices, and other non-file entries during workspace restore snapshot capture/comparison. - Pass a small model-provider API-key allowlist only to plugins declaring `environment.drivers.register`. - Added focused regression tests for remote Claude session params, unsafe session cwd detection, plugin worker env filtering, and non-file snapshot entries. Credits: ports host-side fixes from Jannes' #5823. ## Verification - `pnpm vitest run packages/adapter-utils/src/workspace-restore-merge.test.ts server/src/services/session-workspace-cwd.test.ts server/src/__tests__/claude-local-execute.test.ts server/src/__tests__/plugin-database.test.ts` (25 passed, 7 skipped by existing embedded-Postgres host guard) - `pnpm --filter @paperclipai/adapter-utils typecheck` - `pnpm --filter @paperclipai/adapter-claude-local typecheck` - `pnpm --filter @paperclipai/server typecheck` ## Risks - Low risk: changes are scoped to remote sandbox/session metadata, workspace snapshot filtering, and plugin worker env setup. - Sandbox-provider plugins now receive only the explicit model-provider key allowlist; any provider needing another key name will need a deliberate allowlist update. > 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, GPT-5-based coding agent, tool-enabled local code execution and repository editing. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
012a738729 |
Add ordered sub-issue navigation (#5938)
## Thinking Path > - Paperclip orchestrates AI-agent companies through company-scoped issues, comments, and execution context. > - The issue detail page is the board surface where operators and agents inspect a task in its parent/child workflow. > - Ordered sub-issues need a low-friction way to move through work without returning to the parent list after every issue. > - Existing issue detail navigation only covered sibling transitions and did not continue into a parent issue's first ordered child. > - This pull request adds ordered previous/next navigation for issue detail views and extends it to continue from a parent or last sibling into the first direct child. > - The benefit is a smoother review/execution path through hierarchical work while preserving hidden issue filtering and dependency-aware ordering. ## What Changed - Added `IssueSiblingNavigation` and route-state handling so issue detail footers can link to previous/next ordered issues. - Extended sub-issue ordering helpers to build navigation from siblings plus direct children, including root-parent and last-sibling-to-first-child cases. - Added page, component, and library tests for ordered sibling navigation, child fallback navigation, hidden issues, and link rendering. - Fixed the quicklook blur/click race Greptile found by deferring close until after portaled link clicks can complete, with a regression test. - Polished the navigation landmark label so it remains accurate when the next target is a direct child rather than a sibling. ## Verification - `pnpm exec vitest run src/components/IssueLinkQuicklook.test.tsx src/lib/issue-detail-subissues.test.ts src/components/IssueSiblingNavigation.test.tsx src/pages/IssueDetail.test.tsx --config vitest.config.ts` from `ui/` - 31 tests passed. - `pnpm --filter @paperclipai/ui typecheck` - passed. - `git diff --check` - passed. - GitHub PR checks on latest head `34046be2` - passed: Greptile Review, verify, e2e, Canary Dry Run, policy, Snyk, and serialized server shards. - Screenshots: not captured in this heartbeat; this PR is a draft and the changed states are covered by focused component/page tests. ## Risks - Low risk; this is a UI navigation addition with no database or API contract changes. - The main behavioral risk is navigation ordering drift if `workflowSort` expectations change later. - The IssueDetail navigation now waits for child issue loading, which avoids stale child fallback links but can delay footer navigation briefly while data loads. > 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, GPT-5 coding agent with repository tool use and shell 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
eb452fba30 |
Fix comment date binding regression (#5919)
## Thinking Path > - Paperclip is the control plane for autonomous AI companies, and issue comments are the primary durable communication surface between operators and agents. > - Commit `c445e592` (`fix(ui): fix message attribution for agent-posted comments with user author IDs (#5780)`) added server-side derived attribution for historical comments by scanning heartbeat runs near comment timestamps. > - That scan accidentally bound JavaScript `Date` objects directly into postgres-js SQL fragments for the run timestamp window. > - On real Postgres, that can fail while listing issue comments with `ERR_INVALID_ARG_TYPE`, which makes comments disappear from issue pages such as `PAP-9284`. > - This pull request keeps the attribution behavior intact while changing only the broken timestamp binding path. > - The benefit is that comments load again without weakening the conservative attribution recovery introduced by `c445e592`. ## What Changed - Convert the derived-attribution heartbeat-run window bounds to ISO timestamp strings before binding them into SQL, with explicit `::timestamptz` casts. - Add an embedded Postgres regression that inserts a heartbeat run and user-authored comment, then verifies `issueService.listComments()` returns the comment while the attribution scan runs. - Delete `heartbeat_runs` during the issue service test cleanup before deleting agents so the new test data does not leak across cases. ## Verification - `pnpm exec vitest run server/src/__tests__/issues-service.test.ts -t "lists user comments when derived run attribution scans a timestamp window"` - `pnpm --filter @paperclipai/server typecheck` - `git diff --check` ## Risks - Low risk. The change is limited to how timestamp parameters are bound for an existing query. - The derived attribution logic remains conservative and still requires exact run-log proof before relabeling a comment. - The regression uses embedded Postgres so it covers the postgres-js binding path that failed in production-like local runs. > 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 via the Paperclip `codex_local` adapter; GPT-5 coding-agent family with local terminal, file-editing, and git/GitHub CLI tool use. Exact hosted model deployment ID is not exposed by this local adapter runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots (not applicable: server-side comment API bugfix) - [x] I have updated relevant documentation to reflect my changes (not applicable: no documented behavior or command changed) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
b947a7d76c |
[codex] Improve local plugin development workflow (#5821)
## Thinking Path > - Paperclip is the control plane for autonomous AI-agent companies. > - Plugins are the extension point for adding capabilities without expanding the core product surface. > - Local plugin development needed a tighter CLI-first loop so plugin authors can scaffold, run, install, inspect, and reload plugins without reaching into internal package paths. > - The server plugin install path also needed local-path handling that keeps plugin identity, dashboard routes, and development watchers coherent. > - This pull request adds the CLI scaffold/install workflow, fixes the server and SDK edge cases that blocked that loop, and updates the agent-facing plugin creation skill and docs. > - The benefit is that contributors can develop plugins from local folders with a documented, repeatable happy path. ## What Changed - Added `paperclipai plugin init` coverage and CLI wiring for local plugin scaffolding. - Improved local plugin install handling, plugin key route resolution, dashboard capability behavior, and dev watcher startup/reload behavior. - Fixed plugin SDK worker entrypoint validation for symlinked package layouts. - Added targeted tests for plugin init, server plugin authz/watcher behavior, SDK worker host validation, and the authoring smoke example. - Added a short local plugin development guide and refreshed the plugin authoring guide plus `paperclip-create-plugin` skill instructions. ## Verification - `pnpm run preflight:workspace-links && pnpm --filter @paperclipai/plugin-sdk build && pnpm --filter @paperclipai/create-paperclip-plugin typecheck && pnpm --filter paperclipai typecheck && pnpm --filter @paperclipai/plugin-sdk typecheck && pnpm --filter @paperclipai/server typecheck` - `pnpm exec vitest run --project paperclipai cli/src/__tests__/plugin-init.test.ts` - `pnpm exec vitest run --project @paperclipai/plugin-sdk packages/plugins/sdk/tests/worker-rpc-host.test.ts` - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/plugin-dev-watcher.test.ts --pool=forks --poolOptions.forks.isolate=true` - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/plugin-routes-authz.test.ts --pool=forks --poolOptions.forks.isolate=true` - `pnpm --dir packages/plugins/examples/plugin-authoring-smoke-example test` - Confirmed `pnpm-lock.yaml` is not included in the PR diff. ## Risks - Medium risk: this touches plugin install routing, CLI command behavior, and the local development watcher. - Local path plugin installs execute trusted local code by design; the new docs call out that trust boundary. - No database migrations are included. > 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, GPT-5 coding agent, tool-enabled local shell and git workflow, medium reasoning effort. Context window details were not exposed in this runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge UI screenshots: not applicable; this PR changes CLI/server/plugin docs and tests, not board UI rendering. --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
0808b388ee |
[codex] Add source-scoped recovery actions (#5599)
## Thinking Path > - Paperclip is a control plane for autonomous AI companies, where work must end with a clear disposition rather than ambiguous agent liveness. > - Recovery currently detects stalled or missing-next-step issues, but source issue recovery can become split across child recovery issues, blockers, and comments. > - That makes it harder for operators and agents to see who owns recovery and what exact action is needed on the original issue. > - Source-scoped recovery actions give the original issue a first-class active recovery state with owner, evidence, wake policy, and resolution outcome. > - This pull request adds the recovery-action data model, backend reconciliation and resolution APIs, and board UI indicators/actions. > - The benefit is clearer stalled-work recovery without losing source issue context or relying on comments as the liveness path. ## What Changed - Added the `issue_recovery_actions` schema, shared types/constants/validators, and an idempotent `0084_issue_recovery_actions` migration ordered after current `master` migrations. - Updated stranded/missing-disposition recovery to create source-scoped recovery actions, wake the recovery owner on the source issue, and avoid locking the source issue for recovery-action wakes. - Added API support for reading active recovery actions on issue detail/list surfaces and resolving them with restored, blocked, cancelled, or false-positive outcomes. - Require blocked recovery resolutions to have an unresolved first-class blocker, and removed the UI shortcut that could mark recovery blocked without a blocker selection path. - Surfaced recovery indicators/actions in the issue UI, blocker notices, active run panels, issue rows, and Storybook coverage. - Updated docs and focused tests for recovery semantics, ownership, races, stale comments, and UI behavior. ## Verification - `pnpm exec vitest run server/src/__tests__/issue-recovery-actions.test.ts server/src/__tests__/heartbeat-process-recovery.test.ts ui/src/components/IssueRecoveryActionCard.test.tsx ui/src/components/IssueBlockedNotice.test.tsx ui/src/api/issues.test.ts` — 5 files, 72 tests passed. - `pnpm --filter @paperclipai/shared typecheck` — passed. - `pnpm --filter @paperclipai/db typecheck` — passed, including migration numbering check. - `pnpm --filter @paperclipai/server typecheck` — passed. - `pnpm --filter @paperclipai/ui typecheck` — passed. - Follow-up verification after blocker-resolution guard: `pnpm exec vitest run server/src/__tests__/issue-recovery-actions.test.ts ui/src/components/IssueRecoveryActionCard.test.tsx ui/src/api/issues.test.ts` — 3 files, 27 tests passed. - Follow-up `pnpm --filter @paperclipai/server typecheck` — passed. - Follow-up `pnpm --filter @paperclipai/ui typecheck` — passed. - UI states are available in `ui/storybook/stories/source-issue-recovery.stories.tsx`; screenshot capture helper is `scripts/screenshot-recovery-card.cjs`. ## Risks - Medium: recovery behavior changes from child recovery issue ownership toward source-scoped actions, so operators may see stalled-work state in new places. - Migration risk is mitigated by using the next migration slot after `master` and making the table/constraints/index creation idempotent for anyone who previously applied the old branch-local `0082_dizzy_master_mold` migration. - Existing child recovery issue paths are still guarded for already-created recovery issues, but new source-scoped flows should be watched in CI and Greptile review. > 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, GPT-5 coding agent, tool use enabled for shell, Git, GitHub, and local test execution. Context window not exposed by the runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Chris Farhood
|
b61455373c | Merge updated feat/plugin-acquire-lease-agent-id into dev (adds resumeLease agentId) | ||
|
Chris Farhood
|
73f4685729 |
feat(plugin-sdk): also thread agentId into environmentResumeLease params
Symmetric with the acquireLease change. Lets plugin-backed sandbox providers reject a reusable lease whose stored agentId doesn't match the current run's agent, forcing the host to acquire a fresh lease instead of stomping the previous agent's workspace state. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Chris Farhood
|
7cee02ddf3 |
Merge branch 'feat/plugin-acquire-lease-agent-id' into dev
Thread agentId into PluginEnvironmentAcquireLeaseParams + host call sites so plugin-backed sandbox providers (e.g. paperclip-plugin-k8s) can scope lease state per-agent without needing an SDK callback or DB lookup. |
||
|
Chris Farhood
|
417782a6ec |
feat(plugin-sdk): thread agentId into environmentAcquireLease params
Add an optional agentId field to PluginEnvironmentAcquireLeaseParams and thread it through the host's environment-runtime + run-orchestrator call sites so plugin-backed sandbox providers can scope lease state (subdirs, PVCs, etc.) per agent without an SDK callback or DB lookup. The field is required-but-nullable on the internal EnvironmentDriverAcquireInput (string | null) so every call site has to think about whether it has an agent context. Ad-hoc operator probes (agent test-environment route) pass null. The plugin RPC payload omits the field entirely when null, keeping wire compatibility with older plugin worker SDKs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Devin Foley
|
c445e59256 |
fix(ui): fix message attribution for agent-posted comments with user author IDs (#5780)
## Thinking Path > - Paperclip’s issue chat is an audit surface: reviewers need to trust who actually authored a message. > - Some historical agent comments were persisted with `authorUserId` and no surviving `createdByRunId`, so the UI rendered real agent output as if it came from the board user. > - A pure timestamp-window fallback is too risky because human reviewers can comment while agents are running. > - The safe recovery path is to derive attribution only when the server can prove it from same-issue run logs that include the exact posted comment id, then let the chat renderer prefer that recovered agent attribution. > - This keeps historical threads trustworthy without mutating old database rows or guessing in ambiguous cases. ## What Changed - Added shared `IssueComment` fields for derived attribution so server and UI can carry recovered `derivedAuthorAgentId`, `derivedCreatedByRunId`, and `derivedAuthorSource` consistently. - Added server-side attribution recovery in `server/src/services/issues.ts` that reads same-issue run logs and only derives agent authorship when a run log contains the exact `comment id: ...` emitted during posting. - Updated issue chat rendering in `ui/src/lib/issue-chat-messages.ts` to prefer direct agent authorship, then activity-log `runAgentId`, then the server-derived attribution. - Removed the unsafe UI-only run-window fallback from `ui/src/pages/IssueDetail.tsx` so human comments posted during an active run are not silently relabeled as agent output. - Added regression coverage for both the run-log derivation path and the chat-rendering fallback behavior. - Bounded server-side run-log enrichment to 8 concurrent reads per request and removed the unused `issueCommentSchema` declaration during PR cleanup. ## Verification - `pnpm exec vitest run ui/src/lib/issue-chat-messages.test.ts server/src/__tests__/issues-service.test.ts` - `pnpm test:run:general` - Live validation on May 12, 2026 in `PAPA-322`: confirmed the previously misattributed historical comments on `PAPA-316` now render as Claude-authored on `http://goldie.gerbil-company.ts.net:3100`. - Reviewer check: open `PAPA-316` in the running instance and confirm historical comments such as `## Investigation: exe.dev 422 + codex re-test` render under Claude instead of the board user. ## Risks - Low risk. The change is scoped to comment attribution recovery and rendering. - Derived attribution is intentionally conservative: if there is no exact run-log proof, the comment remains user-authored instead of guessing. - Run-log recovery depends on retained same-issue logs, so older comments without that evidence remain unchanged. ## Model Used - OpenAI Codex via the Paperclip `codex_local` adapter (GPT-5-class coding agent with tool use in the local Paperclip runtime; the exact deployment/model ID is not surfaced by this workspace). ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
9746dab4e8 |
Bump release changelog to v2026.512.0 (#5764)
## Summary PR [#5366](https://github.com/paperclipai/paperclip/pull/5366) already merged the v2026.511.0 changelog. This follow-up bumps the artifact to the actual cut date and drops the pre-alpha sandbox work per maintainer feedback. - **Rename** `releases/v2026.511.0.md` → `releases/v2026.512.0.md` - **Bump header / date** to `# v2026.512.0` / `> Released: 2026-05-12` - **Drop new sandbox content** (pre-alpha, not yet ready): - Daytona sandbox provider plugin highlight ([#5580](https://github.com/paperclipai/paperclip/pull/5580), [#5586](https://github.com/paperclipai/paperclip/pull/5586)) - Cursor sandbox support improvement ([#4803](https://github.com/paperclipai/paperclip/pull/4803)) - Cursor sandbox runtime resolution fix ([#5446](https://github.com/paperclipai/paperclip/pull/5446)) - Sandbox provider messaging polish ([#4902](https://github.com/paperclipai/paperclip/pull/4902)) - **Add LLM Wiki plugin package highlight** ([#5716](https://github.com/paperclipai/paperclip/pull/5716)) — the package itself landed on master after #5366 merged. - **Update Upgrade Guide closer** to mention only the `cursor_cloud` adapter as opt-in. The `cursor_cloud` adapter is kept in (adapter, not sandbox). The exe.dev and Cloudflare sandbox provider plugins that landed since the merge are also excluded as pre-alpha. No breaking changes; the nine new migrations (`0075`–`0083`) carry over unchanged from the merged 511 file. ## Test plan - [ ] Maintainer review of the dropped entries — confirm I caught everything sandbox-related you wanted out - [ ] Confirm Cursor Cloud adapter staying in is intentional (flag for removal if not) - [ ] Confirm LLM Wiki plugin package highlight phrasing 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
563413ecd4 |
Fix LLM wiki type contracts (#5758)
## Thinking Path > - Paperclip is the control plane for autonomous AI companies, and plugins extend that control plane without bloating core. > - The LLM Wiki plugin adds a knowledge surface through the plugin runtime and shared plugin UI components. > - After the LLM Wiki work merged to `master`, CI exposed TypeScript contract drift between plugin code, SDK component types, and update settings types. > - The ingestion settings update path intentionally accepts partial source toggles, but its type intersected with the full settings shape and required every source key. > - The LLM Wiki UI also passes managed routine default-drift metadata through the shared routine list item shape, but that metadata was missing from the public item type. > - This pull request narrows those type contracts to match the existing runtime behavior. > - The benefit is restoring typecheck on `master` with a small, non-behavioral follow-up. ## What Changed - Added a `WikiEventIngestionSettingsUpdate` type that permits partial source updates without weakening normalized stored settings. - Added managed routine default-drift metadata to the plugin SDK `ManagedRoutinesListItem` type. - Mirrored that managed routine default-drift type in the host UI component item type. ## Verification - `pnpm --filter @paperclipai/plugin-llm-wiki typecheck` - `pnpm --filter @paperclipai/plugin-sdk typecheck` - `pnpm --filter @paperclipai/ui typecheck` - `git diff --check` ## Risks - Low risk. This is a TypeScript type-contract fix only; no runtime behavior or database schema changes. > 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, GPT-5-based coding agent, tool-enabled local repository editing and command 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Notes on checklist applicability: no screenshots are included because the UI change is a shared type-only contract update with no visual behavior change; no docs were required because no behavior or commands changed. Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
github-actions[bot]
|
94ce7af715 |
chore(lockfile): refresh pnpm-lock.yaml (#5756)
Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml. Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com> |
||
|
Dotta
|
508355b8fc |
[codex] Add LLM Wiki plugin package to master (#5716)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - The plugin system is the extension surface for optional product capabilities without baking every workflow into core. > - The LLM Wiki plugin package was reviewed in stacked PR #5592, which targeted `pap-9173-llm-wiki-rest`. > - The stack base PR #5597 merged to `master` before #5592 was merged into that branch, so the plugin package never reached `master`. > - A direct PR from `pap-9173-llm-wiki-rest` back to `master` would be noisy because that branch has diverged from current `master`. > - This pull request reapplies the reviewed `packages/plugins/plugin-llm-wiki/` package onto current `master` and updates Docker deps-stage manifest coverage. > - The branch intentionally no longer changes `pnpm-workspace.yaml` after maintainer feedback; because the new package is now a root workspace importer, the remaining integration question is how maintainers want the root lockfile handled under the current PR policy. ## What Changed - Added the LLM Wiki plugin package under `packages/plugins/plugin-llm-wiki/` from the merged PR #5592 head. - Preserved the post-review cleanup from #5592: generated design/screenshot artifacts are not committed, and `src/ui/index.tsx` / `src/wiki.ts` are small public entrypoints. - Added the new plugin package manifest to the Docker deps stage so policy can validate package manifest coverage. - Removed the earlier `pnpm-workspace.yaml` exclusion per maintainer request, so the plugin is included by the existing `packages/plugins/*` workspace glob. ## Verification Current head: - PGlite migration harness: ran migrations 001-003, verified old non-space distillation unique constraints were removed, inserted duplicate cursor and work-item keys in a second space, then reran migration 003 successfully - `node ./scripts/check-docker-deps-stage.mjs` - `git diff --check` Known current-head install result after removing the workspace exclusion: - `pnpm install --frozen-lockfile` fails because `pnpm-lock.yaml` has no importer for `packages/plugins/plugin-llm-wiki/package.json`. Previously verified on the same plugin source before the workspace-exclusion removal: - `pnpm --filter @paperclipai/plugin-sdk build` - `cd packages/plugins/plugin-llm-wiki && pnpm install --lockfile=false && pnpm test` ## Risks - The branch now includes `packages/plugins/plugin-llm-wiki` in the root workspace but does not update `pnpm-lock.yaml`. Root frozen install will fail until maintainers choose a lockfile path that fits repo policy. - Committing `pnpm-lock.yaml` directly on this PR conflicts with the current PR policy check, while excluding the package from `pnpm-workspace.yaml` was rejected in maintainer feedback. - The package includes UI code already reviewed in #5592; generated screenshot/design artifacts were intentionally removed per maintainer request, so visual review should regenerate screenshots locally if needed. - The package depends on plugin host support from #5597, which is already merged to `master`. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via Codex CLI, tool use and local code execution enabled; context window 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 run the targeted checks listed above - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Stack context: #5592 was merged into `pap-9173-llm-wiki-rest` after #5597 had already merged that branch to `master`, so this follow-up PR is needed to carry the plugin package itself into `master`. Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Chris Farhood
|
872dd664ed |
revert(secrets): drop fork's usages-tracking + delete guard
Now that upstream's #5429 provides provider-based secrets management with formal bindings (companySecretBindings table populated at config-save time) plus the /secrets/:id/usage endpoint backed by listBindingReferences(), the fork's parallel usages() scan is redundant for agent/routine bindings. The fork's scan did cover one path upstream doesn't track: skill metadata sourceAuthSecretId references. Dropping this means accidental deletion of a skill's auth secret is no longer rejected — accepted as a chase-upstream tradeoff. - server/src/services/secrets.ts: drop usages(), SecretUsage* types, in-use guard in remove(), and companySkills/agentService imports - server/src/routes/secrets.ts: drop GET /secrets/:id/usages route - ui/src/api/secrets.ts: drop usages() client method Typechecks clean on server and ui. |
||
|
Chris Farhood
|
d9d9bbcf06 |
fix(secrets): drop fork's CompanySecrets page and dedupe sidebar/route
The merge of upstream's #5429 (provider vaults + AWS Secrets Manager) added a new 2,155-line Secrets.tsx page covering everything the fork's 528-line CompanySecrets page did, plus vault management and AWS import. Auto-merge took both sides' sidebar entry and route registration, so React Router picked the fork's older page first and upstream's AWS UI never rendered. - ui/src/App.tsx: drop CompanySecrets import + duplicate route at /company/settings/secrets - ui/src/components/CompanySettingsSidebar.tsx: drop duplicate Secrets nav item - ui/src/pages/CompanySecrets.tsx: delete (superseded) Server-side delete guard (services/secrets.ts: refuse delete when secret is referenced by agents or skills) is preserved and still enforced; upstream's page surfaces the API error message in place of the fork's inline reference list. |
||
|
Chris Farhood
|
c2a49879d5 |
fix(ci): add cursor-cloud adapter package.json to fork Dockerfile deps stage
Upstream #5664 added the cursor-cloud adapter; the .farhoodlabs/Dockerfile overlay was missing the deps-stage COPY for its package.json, so pnpm install didn't wire it as a workspace package and the build stage failed type-checking cursor-cloud's UI sources from ui's tsc -b. |
||
|
Chris Farhood
|
5d0d076704 | chore(docs): remove FAR-108 from pending PR list (k8s adapter dropped) | ||
|
Chris Farhood
|
08dc3d9ff4 |
Merge upstream/master into dev (76 commits)
Resolved 5 conflicts: - .github/workflows/docker.yml, release.yml: kept fork stubs (CI handled by build-prod/build-dev) - server/src/routes/secrets.ts: kept fork's /usages route alongside upstream's /usage, /access-events - server/src/services/secrets.ts: kept fork's usages() function and in-use deletion guard, layered before upstream's soft-delete + provider cleanup in remove() - ui/src/api/secrets.ts: kept fork's usages() method alongside upstream's vault methods Typechecks pass on @paperclipai/shared, @paperclipai/server, @paperclipai/ui. |
||
|
Devin Foley
|
ad0bb57350 |
Fix exe.dev sandbox installs for gemini/opencode local adapters (#5737)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, including running adapter CLIs inside remote sandboxes > - The QA matrix in PAPA-316 spins up local-runtime adapters (claude/gemini/opencode) against both SSH and the new exe.dev sandbox provider, and "Test" exercises the same install + probe path the real runtime uses > - On exe.dev the QA matrix failed at three different points: SSH/sandbox secret refs would not resolve, gemini-local could not find npm, and opencode-local installed a binary that was not on the probe-shell PATH > - These are all environment-shape issues the runtime should handle, not regressions in any individual adapter, so they need to be fixed in the shared install/resolve layer before the matrix can pass > - This pull request wires the environment id through to secret-ref resolution, bootstraps npm from a portable Node tarball when the sandbox image lacks Node, and symlinks the opencode binary into a directory that non-login shells see > - The benefit is that the QA matrix passes end-to-end on exe.dev, and any future sandbox provider that ships without Node or relies on rc-file PATH wiring gets the same fixes for free ## What Changed - `server/src/services/environment-execution-target.ts`: pass the environment `id` into `resolveEnvironmentDriverConfigForRuntime` for both the sandbox and SSH branches, so `privateKeySecretRef` / sandbox-provider secret refs (e.g. exe.dev `apiKey`) can resolve against the secret store at runtime instead of throwing `Runtime secret resolution requires an environment id`. - `packages/adapter-utils/src/sandbox-install-command.ts`: extend `buildSandboxNpmInstallCommand` with an `ENSURE_NPM_PREAMBLE` that, when `npm` is missing, downloads a portable Node v22 tarball into `$HOME/.local` and sets `PAPERCLIP_NPM_BOOTSTRAPPED=1` so the install step skips sudo (sudo's `secure_path` would lose the freshly-installed `npm` in `$HOME/.local/bin`). Distro-packaged Node from apt-get is intentionally avoided because it tends to be too old to parse modern JS syntax used by `@google/gemini-cli`. - `packages/adapters/gemini-local/src/index.ts`: switch the hardcoded `npm install -g @google/gemini-cli` to `buildSandboxNpmInstallCommand`, so gemini-local picks up the same sudo-aware + npm-bootstrap behavior as the other local adapters. - `packages/adapters/opencode-local/src/index.ts`: append a step to the install command that symlinks `$HOME/.opencode/bin/opencode` into `$HOME/.local/bin`. The upstream installer only adds `~/.opencode/bin` to PATH via `~/.bashrc`, which non-login `sh -c` probe invocations do not source. - `packages/adapter-utils/src/sandbox-install-command.test.ts`: cover the new preamble plus the unchanged root/sudo/user-prefix branches. ## Verification - `cd packages/adapter-utils && npm test -- sandbox-install-command` (passes; new "bootstraps npm from a portable Node tarball when missing" case is included). - Manual: ran the in-app `Test` action against the QA matrix dev instance for `QA exe.dev Claude`, `QA exe.dev Gemini`, and `QA exe.dev OpenCode` — all three now report `status=pass` including the hello probe. `QA SSH Claude` also passes; without the environment-id fix, SSH resolution threw before the wrapper / install fixes could run. - Suggested reviewer check: re-run the matrix on a fresh exe.dev environment and confirm the install step no longer hits `npm: command not found` for gemini and the opencode probe no longer hits `opencode: command not found`. ## Risks - Low/medium. The npm bootstrap pins Node `v22.11.0` from `nodejs.org/dist`; if that URL becomes unreachable the install will fail with a clear `curl` error rather than corrupting state. The bootstrap path is only taken when `npm` is genuinely missing, so existing sandbox images that ship with Node are unaffected. - The opencode symlink uses `ln -sf` into `$HOME/.local/bin`, which is created with `mkdir -p`; idempotent on re-install. - The `id` change is a strict additive: callers previously got `undefined` and only the secret-ref code paths actually read it. No behavior change for environments without secret refs. ## Model Used - Claude (Anthropic), `claude-opus-4-7`, with extended thinking and tool use enabled. Iterated through the Paperclip QA matrix harness; no other model 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots (n/a — runtime/install path only) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
eaa80cf88b |
Enable CI publishing for cursor-cloud, cloudflare, and exe.dev release packages (#5728)
## Thinking Path > - Paperclip orchestrates AI agents, and its release flow depends on explicit package enrollment for automated publishing. > - The release registry tooling uses `scripts/release-package-manifest.json` as the source of truth for which public packages CI is allowed to publish. > - The cursor cloud adapter plus the Cloudflare and exe.dev sandbox plugins are public packages that now need to ship through the normal CI release path. > - Leaving those entries at `publishFromCi: false` keeps release automation and registry validation out of sync with the intended package set. > - This pull request updates only those three manifest entries and leaves the release tooling itself unchanged. > - The benefit is that CI release enrollment now matches the packages we intend to publish, with the existing manifest checks continuing to guard correctness. ## What Changed - Enabled CI publishing for `@paperclipai/adapter-cursor-cloud` in `scripts/release-package-manifest.json`. - Enabled CI publishing for `@paperclipai/plugin-cloudflare-sandbox` in `scripts/release-package-manifest.json`. - Enabled CI publishing for `@paperclipai/plugin-exe-dev` in `scripts/release-package-manifest.json`. ## Verification - `node ./scripts/release-package-map.mjs check` - `pnpm test:release-registry` ## Risks - Low risk. This is a manifest-only change, but a wrong enrollment flag would affect release automation, so the release-registry checks are the main guardrail. ## Model Used - OpenAI GPT-5.4 via Paperclip `codex_local` (`adapterConfig.model: gpt-5.4`), high reasoning effort, with tool use and shell/code execution. The adapter does not expose a separate context-window value in this environment. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge |
||
|
Dotta
|
8af38fb054 |
Revert "fix(ui): prevent lossy cron rewrites + redesign routine triggers tab" (#5725)
## Thinking Path > - Paperclip orchestrates AI agents through visible, governable task and routine workflows. > - Routines are the recurring-work surface where operators configure schedules, runs, and activity. > - PR #3569 moved routine operational tabs into the right-hand properties panel while also redesigning the routine trigger editor. > - The current product request is to remove that routine properties right-tab change for now and come back to it later. > - The cleanest way to do that is a direct revert of #3569 on top of current `master`, which already includes the #5703 revert. > - This pull request restores the pre-#3569 routine trigger/detail behavior and removes the right-tab properties-panel routine layout. > - The benefit is a simple, reviewable rollback with no schema or API changes. ## What Changed - Reverted #3569: `fix(ui): prevent lossy cron rewrites + redesign routine triggers tab`. - Restored the previous `RoutineDetail` inline tabs and trigger editing flow. - Restored the earlier `ScheduleEditor` implementation. - Removed the UI components and tests introduced by #3569: `ConfirmDialog`, `TriggerDialog`, `TriggerListCard`, and `ScheduleEditor.test.ts`. ## Verification - `git diff --check origin/master..HEAD` - `pnpm vitest run ui/src/pages/Routines.test.tsx ui/src/components/RoutineHistoryTab.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` Notes: - `pnpm install --frozen-lockfile` was run in the clean worktree before verification. It completed with known workspace bin-link warnings for `paperclip-plugin-dev-server` because the plugin SDK `dist/dev-cli.js` has not been built in that fresh worktree. - `Routines.test.tsx` emitted existing Radix dialog accessibility warnings during the test run; the tests passed. ### Screenshots This is a direct revert of #3569. The visual state after this PR corresponds to the old screenshot from #3569, and the state being removed corresponds to the new/right-panel screenshots from #3569. | Before this revert | After this revert | | --- | --- | | <img width="1410" height="1325" alt="routine-triggers-before-this-revert" src="https://github.com/user-attachments/assets/d70dd35b-e72f-4fc6-bb21-be9b0d92b3b1" /> | <img width="721" height="707" alt="routine-triggers-after-this-revert" src="https://github.com/user-attachments/assets/260bb682-32cb-4dff-b038-d55e45824b04" /> | Right-hand properties panel state removed by this revert: <img width="1409" height="830" alt="routine-properties-panel-removed" src="https://github.com/user-attachments/assets/f1d42f07-7cd3-4614-8e93-5b585affd4bf" /> ## Risks - Low technical risk: this is a clean Git revert of a UI-only PR. - Product risk: #3569 also fixed lossy cron editing and added broader schedule presets, so this rollback intentionally removes those improvements along with the right-tab routine layout. - Follow-up risk: if we want only the schedule-editor fixes back later, they should be reintroduced separately from the routine properties-panel layout. > 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, GPT-5 coding agent, tool-enabled with local shell and GitHub CLI access. Context window size was 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
0c6f9bdcf8 |
Revert "fix(ui): improve routine properties panel and history UX" (#5723)
## Thinking Path > - Paperclip orchestrates AI agents through visible, governable task and routine workflows. > - The routines UI includes the routine detail page, properties panel, history tab, and shared sidebar components. > - PR #5703 changed that workflow by widening the routine properties panel and moving revision inspection/comparison into dialogs. > - The product direction for that change is being paused for now, so the safest path is a direct revert instead of partial edits. > - This pull request reverts merge commit `74cb560c41305ac3283067d1ec8d3060ffdc28cb` from #5703. > - The benefit is restoring the prior routines UI behavior while keeping the revert easy to review and re-apply later if needed. ## What Changed - Reverted #5703: `fix(ui): improve routine properties panel and history UX`. - Restored the previous routine properties panel sizing, panel context API, routine detail layout, and routine history rendering behavior. - Removed the reverted sidebar pane test additions and restored the previous focused routine history test expectations. ## Verification - `git diff --check origin/master..HEAD` - `pnpm vitest run ui/src/components/RoutineHistoryTab.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` ### Screenshots This is a direct revert of #5703. The visual state after this PR corresponds to the "Before" screenshots from #5703, and the state being removed corresponds to the "After" screenshots from #5703. #### Trigger Panel Width | Before this revert | After this revert | | --- | --- | | <img width="1742" height="1288" alt="triggers-before-this-revert" src="https://github.com/user-attachments/assets/9e818978-283c-49a3-9401-879be550c67b" /> | <img width="1741" height="1289" alt="triggers-after-this-revert" src="https://github.com/user-attachments/assets/2a391769-c355-4219-8da3-d1ea18698430" /> | #### History Panel | Before this revert | After this revert | | --- | --- | | <img width="1741" height="1290" alt="history-before-this-revert" src="https://github.com/user-attachments/assets/4c139238-8494-4438-89e1-4277d05bc3aa" /> | <img width="1739" height="1289" alt="history-after-this-revert" src="https://github.com/user-attachments/assets/eaea4f3d-bb65-4af6-b67f-3ba3026fe0c9" /> | ## Risks - Low technical risk: this is a clean Git revert of a recently merged UI-only PR. - Product risk: the routine properties panel and revision history return to the older, narrower workflow that #5703 was improving. - Re-application risk: future work that wants the #5703 behavior back should re-apply it deliberately rather than cherry-picking around this revert. > 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, GPT-5 coding agent, tool-enabled with local shell and GitHub CLI access. Context window size was 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
21404e8a34 |
[codex] Fix Docker build without LLM wiki plugin package (#5714)
## Thinking Path > - Paperclip is the control plane for autonomous AI companies, and its Docker image needs to build from the checked-in core repository. > - The Docker `deps` stage copies workspace package manifests before running `pnpm install --frozen-lockfile` so dependency installation can be cached. > - Current `master` copied `packages/plugins/plugin-llm-wiki/package.json`, but that plugin package has not been merged into core yet. > - Docker fails before install with a missing build-context path, so the release image cannot build from the current repository state. > - This pull request removes the premature plugin manifest copy while leaving the plugin SDK and existing sandbox plugin package copies intact. > - The benefit is that the Docker build no longer depends on an unmerged plugin package. ## What Changed - Removed the `packages/plugins/plugin-llm-wiki/package.json` copy from the Dockerfile `deps` stage. ## Verification - `git diff --check` - Static Dockerfile source validation: parsed non-stage `COPY` sources and confirmed every source exists in the build context. - Attempted `docker build --target deps --progress=plain -t paperclip-pap-9235-deps-check .`, but Docker is unavailable in this execution environment: `Cannot connect to the Docker daemon at unix:///Users/dotta/.docker/run/docker.sock`. ## Risks - Low risk. The removed path points to a package that is absent from the repository, so retaining it is what breaks the build. The plugin can add its manifest copy back when the package itself lands. > 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 using GPT-5, tool-enabled coding agent in a local repository workspace. Exact context-window metadata is not exposed in this runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
5a64cf52a1 |
Add exe.dev sandbox provider plugin (#5688)
> _Stacked on top of #5685 → #5686 → #5687. Diff against master includes commits from earlier PRs in the stack — review focuses on the two new commits (`Add long-secret textarea variant to JsonSchemaForm SecretField` + `Add exe.dev sandbox provider plugin`)._ ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Each agent runs in a sandbox environment, and operators choose the provider — today E2B, Daytona, and (in this stack) Cloudflare > - exe.dev offers per-VM sandboxes via a small CLI / HTTP API — useful for operators who want full Linux VMs (vs container/runtime-only sandboxes) > - The plugin shape mirrors the e2b plugin: lifecycle hooks (`new`, `ls`, `rm`) drive exe.dev's CLI; SSH plumbing handles direct VM access for adapters that need it > - exe.dev VMs come up bare — `node` is not preinstalled, so the Paperclip sandbox callback bridge (a Node script) needs Node 20 installed at VM init via `--setup-script`. The plugin defaults the setup script to a Nodesource install > - The auth field accepts long SSH private keys, which need a textarea variant of the existing `SecretField` in `JsonSchemaForm` — added behind a `maxLength > THRESHOLD` opt-in so other secret fields are unaffected > - The benefit is that operators get exe.dev as a fully working sandbox provider out of the box, with no manual VM provisioning required ## What Changed **Shared UI support (`Add long-secret textarea variant to JsonSchemaForm SecretField`):** - `ui/src/components/JsonSchemaForm.tsx` + new `JsonSchemaForm.test.tsx`: when a secret-formatted field declares `maxLength` larger than the existing single-line threshold, render a monospace textarea instead of the masked input. Short secrets (API keys, tokens) keep the existing masked-input + show/hide toggle behavior. **The exe.dev plugin (`Add exe.dev sandbox provider plugin`):** - `packages/plugins/sandbox-providers/exe-dev/`: plugin entry, manifest, plugin runtime, README, and 19-test Vitest suite. - Manifest fields: API token (with `secret-ref` + `/exec` permission notes — needs `new`, `ls`, `rm`), API URL override, optional SSH username, optional SSH private key (uses the new `JsonSchemaForm` textarea variant via `maxLength: 4096`), optional SSH identity-file path, optional setup script. - Default `--setup-script` is a Nodesource Node 20 install. exe.dev VMs come up bare and the Paperclip sandbox callback bridge is a Node script, so without Node preinstalled the bridge can't start. Operators can override by supplying their own setup script. - `runLifecycleCommand` redacts env values from the executed command before surfacing it in error messages, so secrets passed via `--env=KEY=VALUE` don't leak into operator-visible failures. - The plugin distinguishes exe.dev's SSH onboarding failures (`Please complete registration by running: ssh exe.dev`) from general SSH failures and surfaces a clear remediation message. - `scripts/release-package-manifest.json`: register the new plugin for CI publish alongside the existing daytona / e2b providers. ## Verification - `pnpm typecheck` - `pnpm exec vitest run --no-coverage ui/src/components/JsonSchemaForm.test.tsx` - `(cd packages/plugins/sandbox-providers/exe-dev && pnpm test)` — 19 passing For an operator-side smoke test: 1. Get an exe.dev API token with `/exec` permission for `new`, `ls`, `rm`. 2. Register the plugin in your Paperclip instance, configure an environment with the token. 3. Create a sandbox env whose provider is `exe-dev`, then run a Codex or Claude job against it. The default Node 20 setup script should bring the VM up automatically. ## Risks - Adds a new sandbox provider plugin that follows the existing daytona / e2b shape; behavior on existing providers is unchanged. - The `JsonSchemaForm` textarea variant only engages for fields that opt in via `maxLength` larger than the existing threshold. All existing secret fields (which don't declare a `maxLength`) keep their current rendering. Test coverage pins both paths. - The redaction in `runLifecycleCommand` is a defense-in-depth measure; the test suite exercises the redaction path. If the redaction misses a future env-arg shape, the worst case is restored behavior (secrets in error messages), which is what the existing daytona / e2b plugins also do today. - Default setup script downloads from `deb.nodesource.com` over HTTPS at VM init. Operators on air-gapped networks or with a different package strategy can override the setup script. ## Model Used - Provider: Anthropic - Model: Claude Opus 4.7 (1M context) - Capabilities used: extended reasoning, tool use (Read/Edit/Bash/Grep) ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — UI change is a textarea variant of an existing secret field; will attach screenshots before requesting merge - [x] I have updated relevant documentation to reflect my changes (plugin README, manifest descriptions) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Aron Prins
|
74cb560c41 |
fix(ui): improve routine properties panel and history UX (#5703)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Routines are the recurring-work surface where operators configure schedules, executions, activity, and revision history. > - The routine detail view uses a contextual right properties panel for triggers, runs, activity, and history. > - That panel was too cramped for routine workflows: the routine header could collapse at constrained widths, and revision previews/comparisons were trying to live inside the same narrow panel. > - This pull request makes the routine properties panel wider and responsive without changing the default panel behavior for other pages. > - It also moves routine revision viewing and comparison into focused dialogs so history stays usable instead of rendering dense revision content inside the right panel. > - The benefit is a cleaner routine workflow: triggers remain scannable, the main routine stays readable, and revisions can be inspected, compared, and restored without fighting the sidebar width. ## What Changed - Added optional per-panel layout options for storage key, default width, min/max width, and compact viewport behavior. - Set the routine properties panel to use its own 400px default width and persistence key, while compacting to 320px on narrower viewports. - Made the shared resizable sidebar support right-side panes, custom width bounds, compact max width, and keyboard resizing. - Fixed the routine detail header so title text and action controls remain readable beside the properties panel at constrained widths. - Reworked routine history so selecting a revision opens a read-only snapshot dialog instead of trying to render the whole revision inside the right panel. - Added a side-by-side current-vs-selected revision comparison dialog with clearer diff markers for structured fields, triggers, and variables. - Added focused tests for the resizable pane and routine history behavior. ## Verification - `pnpm vitest run ui/src/components/RoutineHistoryTab.test.tsx ui/src/components/ResizableSidebarPane.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm -r typecheck` - `git diff --check` - Browser E2E in TestCo at `http://localhost:3100/TES/dashboard`: - created and edited a routine - added, edited, toggled, and deleted schedule triggers - paused automation - ran the routine and stopped the live run - verified runs, activity, history, snapshot dialog, compare mode, restore confirmation, routine list, recent runs, row actions, panel close/reopen, and constrained-width layout ### Screenshots #### Trigger Panel Width | Before | After | | --- | --- | | <img width="1741" height="1289" alt="triggers-before" src="https://github.com/user-attachments/assets/2a391769-c355-4219-8da3-d1ea18698430" /> | <img width="1742" height="1288" alt="triggers-after" src="https://github.com/user-attachments/assets/9e818978-283c-49a3-9401-879be550c67b" /> | #### History Panel Before, selecting a revision attempted to show dense revision content inside the already narrow right panel. After, history remains a compact list and revision details open separately. | Before | After | | --- | --- | | <img width="1739" height="1289" alt="history-before" src="https://github.com/user-attachments/assets/eaea4f3d-bb65-4af6-b67f-3ba3026fe0c9" /> | <img width="1741" height="1290" alt="history-after" src="https://github.com/user-attachments/assets/4c139238-8494-4438-89e1-4277d05bc3aa" /> | #### Revision Snapshot The selected revision now opens in a dedicated read-only dialog instead of crowding the properties panel. <img width="1740" height="1289" alt="revision-single" src="https://github.com/user-attachments/assets/f930f50f-7016-434b-bd81-d8d97304c528" /> #### Revision Compare Historical revisions can be compared side-by-side with the current revision, including changed structured fields and trigger differences. <img width="1740" height="1287" alt="revision-compare" src="https://github.com/user-attachments/assets/5640201e-de4f-446b-8941-1b0f140c56d7" /> ## Risks - Low to moderate UI risk: the shared resizable pane API gained optional layout parameters, but existing callers keep the previous defaults. - Routine history now uses dialogs for revision viewing and comparison, so reviewers should confirm the new workflow feels right for restore and compare. - Routine panel width now persists under a routine-specific key, so previous global properties panel width preferences do not carry into routines. > 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, GPT-5 coding agent in Codex Desktop, tool-enabled with local shell, git, and in-app browser automation. Context window size was 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge |
||
|
Devin Foley
|
486fb88a15 |
Add Cloudflare sandbox provider plugin (#5687)
> _Stacked on top of #5685 → #5686. Diff against master includes commits from earlier PRs in the stack — review focuses on the two new commits (`Extend sandbox callback bridge for Worker-hosted plugins` + `Add Cloudflare sandbox provider plugin`)._ ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Each agent runs in a sandbox environment, and operators choose which provider backs that sandbox — today E2B and Daytona are bundled with the platform > - Cloudflare Workers + Durable Objects + the Sandbox SDK offer a credible new option: globally distributed, cheap idle, and operator-deployable as a single Worker > - To plug it in, Paperclip needs (a) a provider plugin that speaks the `PaperclipPluginManifestV1` lifecycle and (b) a small operator-deployed Worker — the **bridge** — that adapts Paperclip's runtime RPCs to the Cloudflare Sandbox SDK > - The plugin extends the existing sandbox-callback-bridge with a `bridge.transport: "worker"` discriminator so the platform routes runtime RPCs through the Worker bridge instead of the in-process runner > - This pull request adds the plugin, the bridge Worker template, and the supporting adapter-utils + server hooks the new transport needs > - The benefit is that operators can run sandboxes on Cloudflare's edge with no new platform code beyond installing the plugin and deploying the Worker ## What Changed **Shared support (`Extend sandbox callback bridge for Worker-hosted plugins`):** - `packages/adapter-utils/src/sandbox-callback-bridge.{ts,test.ts}`: expose `expectedHostHeader` so plugin-side bridge clients can verify the canonical request envelope before forwarding. - `packages/adapter-utils/src/command-managed-runtime.{ts,test.ts}`: relax the always-fresh runner construction so callers can re-use a runner across exec calls (Worker-hosted bridges hold the runner inside a Durable Object). - `server/src/services/environment-runtime.ts` + `environment-runtime.test.ts`: route Worker-hosted bridges through the same env-shaping path as E2B and pin the `requestEnv` contract. - `server/src/services/plugin-environment-driver.ts`: thread an optional `issueId` through the runtime descriptor so bridges can scope leases to the originating issue (used by Cloudflare to map a sandbox to the issue/workflow for billing and audit). - `packages/plugins/sdk/src/protocol.ts`: add `issueId?` to `PluginEnvironmentDriverBaseParams` and the new `bridge.transport: "worker"` discriminator that the new plugin declares. - `server/__tests__/heartbeat-plugin-environment.test.ts`: pin the heartbeat path against the new runtime descriptor. **The Cloudflare plugin itself (`Add Cloudflare sandbox provider plugin`):** - `packages/plugins/sandbox-providers/cloudflare/`: plugin entry, manifest, plugin runtime (lifecycle + bridge client), config parsing, and Vitest coverage. Manifest declares `bridge.transport: "worker"` so the platform routes runtime RPCs through the bridge client. - `bridge-template/`: a Worker template the operator deploys with `wrangler`. Owns Durable Object-backed sessions (`sessions.ts`), exec/stream routes (`exec.ts`, `routes.ts`), and an HMAC auth layer (`auth.ts`) that pins the `Host` header surface. Includes the SDK-contract-correct exec implementation, lease recovery, and chunked stdout/stderr streaming. - Tests cover lease/session handoff (`bridge-template/src/exec.test.ts`, `routes.test.ts`), bridge client request shaping (`src/bridge-client.test.ts`), and end-to-end plugin behavior (`src/plugin.test.ts`) including streamed exec output. 27 tests in total. - `README.md` walks the operator through deploying the bridge Worker, registering the plugin, and configuring the runtime. ## Verification - `pnpm typecheck` - `pnpm exec vitest run --no-coverage packages/adapter-utils/src/sandbox-callback-bridge.test.ts packages/adapter-utils/src/command-managed-runtime.test.ts server/src/__tests__/environment-runtime.test.ts server/src/__tests__/heartbeat-plugin-environment.test.ts` - `(cd packages/plugins/sandbox-providers/cloudflare && pnpm test)` — 27 passing For an operator-side smoke test: 1. Deploy the bridge: `cd packages/plugins/sandbox-providers/cloudflare/bridge-template && wrangler deploy` 2. Register the plugin in your Paperclip instance, point its bridge URL at the deployed Worker, set the HMAC shared secret. 3. Create a sandbox environment whose provider is `cloudflare`, then run a Codex or Claude job against it. ## Risks - Adds a new `bridge.transport: "worker"` code path, but the existing E2B / Daytona transports go through the same shaped helpers and have explicit test coverage that pins their behavior unchanged. - The Worker bridge stores session state in a Durable Object; operator instances must be aware of the corresponding Cloudflare costs (DO requests, storage). Documented in the README. - The `issueId` plumbing is optional throughout — existing plugins that don't supply it continue to work. ## Model Used - Provider: Anthropic - Model: Claude Opus 4.7 (1M context) - Capabilities used: extended reasoning, tool use (Read/Edit/Bash/Grep) ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — N/A, no UI change - [x] I have updated relevant documentation to reflect my changes (plugin README, bridge-template README) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
4ad1c83b84 |
Write release changelog for v2026.511.0 (#5366)
## Summary - Adds the user-facing stable release changelog at `releases/v2026.511.0.md`, generated per [`.agents/skills/release-changelog/SKILL.md`](../blob/master/.agents/skills/release-changelog/SKILL.md) from the 89 commits between `v2026.428.0` and `origin/master`. - Surfaces nine headline themes: planning mode, full company search, routine revision history, recovery system notices, expanded plugin host, **secrets provider vaults + remote import**, **Cursor cloud adapter**, **Daytona sandbox provider plugin**, and the ACPX local adapter — plus categorized improvements/fixes. - Documents nine new additive/idempotent migrations (`0075`–`0083`) in the Upgrade Guide, including the `fuzzystrmatch` extension requirement for company search and the `provider_config_id` text→uuid retype on `company_secrets`. Branch retains its `release/v2026.506.0` name to avoid PR churn; only the artifact filename and content track the actual release date. Branch was rebased onto current `origin/master` and force-pushed with a single squashed commit. No `BREAKING:` / `BREAKING CHANGE:` / `feat!:` signals across the full range. ## Test plan - [ ] Maintainer review of the draft changelog content for tone/scope - [ ] Confirm the headline grouping reflects intended release messaging - [ ] Confirm the migration list and upgrade guide match runtime behavior - [ ] Confirm the `0083` `provider_config_id` retype guidance is acceptable for the release notes 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Aron Prins
|
c0c58d6b01 |
fix(ui): prevent lossy cron rewrites + redesign routine triggers tab (#3569)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Humans configure when those agents run via **routines**, which are driven by cron-backed triggers > - The routine detail page exposed triggers through an always-visible inline add form and per-row inline editor, with a ScheduleEditor that only understood a narrow set of cron shapes > - That combination was actively lossy: pasting `0 9,13,17 * * *` silently collapsed to `0 10 * * *` on save, and common shapes (every-N-minutes within a window, multiple times per day, monthly on several dates) had no first-class UI > - This pull request rebuilds the triggers tab around a list of cards + add/edit modal, teaches ScheduleEditor the cron shapes users actually want, and prevents cron round-trips from dropping data > - It also *optionally* tucks the Triggers/Runs/Activity tabs into the shared right-hand PropertiesPanel (same pattern as Issues and Goals) so they stay in view alongside the routine instead of being hidden below the main content > - The benefit is that routine scheduling becomes non-destructive and legible — operators can see, describe, and edit real-world schedules without dropping into raw cron and without fear that saving will silently rewrite their trigger ## What Changed **Core fixes + redesign (required):** - **ScheduleEditor correctness** — `parseCronToPreset` now detects comma lists, ranges, steps, and unknown tokens across every cron field and routes anything it can't round-trip losslessly to the `custom` preset (except `dow === "1-5"` → `weekdays`). Fixes the `0 9,13,17 * * *` → `0 10 * * *` regression. - **ScheduleEditor presets** — adds first-class support for every-N-minutes (with optional hour window + weekdays-only), every-N-hours, hourly at minute offset, daily with multiple times/day, selected-days-of-week with multiple times, and monthly on multiple dates. `describeSchedule` unfolds multi-value hour/day lists into readable sentences. - **ScheduleEditor polish** — swaps raw `<input type=\"checkbox\">` for the shadcn `Checkbox` primitive so hour-window and weekdays-only toggles match the rest of the app. - **Triggers tab redesign** — replaces the inline add form + inline editor with a header + \"Add trigger\" button, compact `TriggerListCard` entries, and a `TriggerDialog` add/edit modal. Enable/disable is now a single-click switch on each card; delete goes through a `ConfirmDialog`. - **Webhook trigger gating** — webhook kind is visible but disabled with \"— COMING SOON\" in the add dialog, matching the old inline form's production behaviour. Editing existing webhook triggers still works. - **Tests** — adds `ScheduleEditor.test.ts` covering the regression cron strings (`0 9,13,17 * * *`, `0 */4 * * *`, `0 10,16 * * *`) plus existing preset patterns as regression guards in the other direction. **Optional layout change (commit `145a86b5` — can be dropped without affecting the rest):** - Moves Triggers/Runs/Activity into the shared right-hand `PropertiesPanel` (persisted open/close, header toggle button), mirroring `IssueDetail` and `GoalDetail`. The reasoning: these tabs are the primary way a human *operates* a routine, and keeping them docked on the right means they're always in view next to the routine content rather than hidden below the fold. Mobile parity is preserved by rendering the same tabs inline below `md`. Trigger cards and run/activity rows were restructured into vertical stacks so they fit the 320px panel without overflow, and the last-result badge became a wrapping inline chip so long error strings no longer fill the card width. - **If reviewers prefer to keep the tabs inline below the routine, this commit can be reverted cleanly without touching any of the fixes above.** ## Screenshots: Old: <img width="721" height="707" alt="triggers-old" src="https://github.com/user-attachments/assets/260bb682-32cb-4dff-b038-d55e45824b04" /> New: <img width="1410" height="1325" alt="Screenshot 2026-04-13 at 12 25 00" src="https://github.com/user-attachments/assets/d70dd35b-e72f-4fc6-bb21-be9b0d92b3b1" /> New Add Trigger modal: <img width="1408" height="1321" alt="Screenshot 2026-04-13 at 12 25 07" src="https://github.com/user-attachments/assets/0f23a83d-ba2c-47ed-9efa-829e777dcdf5" /> Commit 145a86b5 Properties panel: <img width="1409" height="830" alt="commit-145a86b51265e326160cb8c48e0874cb36d86f37" src="https://github.com/user-attachments/assets/f1d42f07-7cd3-4614-8e93-5b585affd4bf" /> ## Verification - `cd ui && npm test -- ScheduleEditor` — new cron parser/describer cases pass. - Full UI test suite + typecheck green locally. - Manual: 1. Open a routine → Triggers tab → verify cards render with enable switch, edit, and delete (confirm dialog). 2. Create a schedule trigger with each preset (every-N-min with window, every-N-hours, hourly@offset, daily multi-time, weekly multi-time, monthly multi-date) → save → reopen → preset + values round-trip intact. 3. Paste `0 9,13,17 * * *` into an existing trigger → editor routes to Custom with the raw cron preserved → save → value unchanged. 4. Try to add a webhook trigger → kind option shows \"— COMING SOON\" and is disabled; edit an existing webhook trigger still works. 5. Toggle the properties panel via header button → state persists across reload. Resize below `md` → tabs render inline. - **Before/after screenshots:** attached in PR description (inline triggers tab → list+modal; raw-cron save hazard → custom preset preservation; bottom-of-page tabs → right-hand PropertiesPanel). ## Risks - **Medium-low.** UI-only change; no API, schema, or migration impact. - `parseCronToPreset` / `describeSchedule` signatures are preserved, but their *behaviour* shifts: more cron strings now resolve to `custom` than before. Any external caller relying on the old (lossy) classification would see different preset tags — none known in-repo. - PropertiesPanel reuse (optional commit) depends on the existing localStorage key behaviour; if two routes ever write conflicting open/close state under the same key, one could clobber the other. Mirrors the established `IssueDetail`/`GoalDetail` pattern, so risk is bounded. Reverting `145a86b5` removes this risk entirely while keeping the fixes. - Webhook kind is disabled in the add dialog only; existing webhook triggers remain editable, so no data is stranded. ## Model Used - **Authoring / PR drafting:** Anthropic Claude — `claude-opus-4-6` (1M context window), via Claude Code CLI. Used for diff review and PR description drafting. Code authored by @aronprins. - **Post-hoc audit:** OpenAI Codex — `gpt-5.4` (high reasoning). Audited the completed work after implementation; found no issues. ## Checklist - [x] Thinking path traces from project context to this change - [x] Model used specified with version + capability details - [x] Tests run locally and pass - [x] Added/updated tests (`ScheduleEditor.test.ts`) - [x] Before/after screenshots attached - [ ] Documentation updated — none required (internal UI only) - [x] Risks documented - [x] Will address all Greptile + reviewer comments before merge |
||
|
Devin Foley
|
0fe39a2d5c |
fix(cursor-local): resolve sandbox agent installs from cursor bin (#5686)
> _Stacked on top of #5685 (Harden remote sandbox runtime). Diff against master includes commits from earlier PRs in the stack — review focuses on the new commit only._ ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The cursor-local adapter wraps the Cursor Agent CLI so a Paperclip workflow can drive it inside a sandbox > - When the adapter runs in a remote sandbox, the Cursor Agent CLI installs under `$HOME/.local/bin/cursor-agent` (or wherever `$XDG_BIN_HOME` points), not on the global PATH > - The existing post-install resolution assumed `cursor-agent` would resolve via the sandbox's login shell PATH after `npm install -g`, which fails on sandboxes where the install lands in a user-prefixed directory that isn't on PATH at probe time > - This pull request resolves the agent CLI from the cursor binary's own directory (`dirname "$(command -v cursor)"`) so the install probe and execute path agree on a real binary location > - The benefit is that cursor-local works correctly on any sandbox provider where `npm install` lands in a user-prefixed directory ## What Changed - `packages/adapters/cursor-local/src/server/remote-command.ts`: resolve the cursor-agent binary from the cursor bin directory after install, instead of relying on PATH. - `packages/adapters/cursor-local/src/server/test.ts`: corresponding probe tweak. - `packages/adapters/cursor-local/src/server/test.test.ts` (new) + `remote-command.test.ts`: focused coverage that exercises the install + resolve path against a sandbox runner that places the binary in a user-prefixed directory. ## Verification - `pnpm exec vitest run --no-coverage packages/adapters/cursor-local/src/server/test.test.ts packages/adapters/cursor-local/src/server/remote-command.test.ts packages/adapters/cursor-local/src/server/execute.test.ts` All passing locally. ## Risks - Local cursor-local runs are unaffected — the resolution change only kicks in for the sandbox install path. - Low risk; isolated to one adapter. ## Model Used - Provider: Anthropic - Model: Claude Opus 4.7 (1M context) - Capabilities used: tool use (Read/Edit/Bash), no code execution beyond local repo commands ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — N/A, no UI change - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
b24c6909e8 |
Harden remote sandbox runtime probes, timeouts, and installs (#5685)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Each agent runs inside a sandbox environment so its CLI is isolated from the host > - Sandbox-backed adapter runs go through a small set of shared helpers — `ensureAdapterExecutionTargetCommandResolvable`, the sandbox callback bridge runner, and per-adapter `SANDBOX_INSTALL_COMMAND` strings > - When standing up new sandbox provider plugins, the existing helpers timed out, missed install fallbacks, or leaned on assumptions that only held for E2B > - Local adapters (`claude-local`, `codex-local`, `gemini-local`, `opencode-local`) needed slightly hardened probes so they could install themselves and validate inside *any* remote sandbox transport, not just E2B > - This pull request bundles those runtime fixes so future sandbox provider plugins inherit a working baseline > - The benefit is that adding a new sandbox provider plugin no longer requires touching adapter-utils or each local-adapter probe — the supporting infra is already correct ## What Changed - `packages/adapter-utils/src/execution-target.ts`: introduce `DEFAULT_REMOTE_SANDBOX_ADAPTER_TIMEOUT_SEC = 1800` and `resolveAdapterExecutionTargetTimeoutSec(...)`. Local and SSH adapters keep the historical "0 means no adapter timeout" behavior; sandbox-backed runs without an explicit `timeoutSec` get an explicit 30-minute default so remote installs and warm-up don't time out at the per-RPC default. Plumbed `timeoutSec` through `ensureAdapterExecutionTargetCommandResolvable` so install probes inside a sandbox honor adapter-level overrides instead of the bridge's 5-minute default. - `packages/adapters/opencode-local/src/index.ts`: switch `SANDBOX_INSTALL_COMMAND` from `npm install -g opencode-ai` to `curl -fsSL https://opencode.ai/install | bash`. The npm package reifies four large prebuilt-binary subpackages in parallel even though only one matches the host arch; on bandwidth-constrained sandboxes that blew through the 240s install budget. The official installer fetches one arch-specific binary and adds `$HOME/.opencode/bin` to PATH via `~/.bashrc`, which the sandbox-callback-bridge login-shell script already sources. - `packages/adapters/{claude,codex,gemini,opencode}-local/`: harden remote-target probes — pass `--skip-git-repo-check` for Codex when probing outside a repo, normalize permission flags for Claude, and add `*.remote.test.ts` coverage that exercises the remote-sandbox path explicitly for each adapter. - `packages/adapter-utils/src/sandbox-install-command.{ts,test.ts}` (new): add `buildSandboxNpmInstallCommand` helper. `server/src/adapters/registry.ts` + new `server/src/__tests__/adapter-registry.test.ts`: wire adapter install commands so they fall back to a writable `$HOME/.local` prefix when global install isn't available. - `server/src/__tests__/plugin-worker-manager.test.ts` + new `server/src/__tests__/fixtures/plugin-worker-delayed.cjs`: pin per-call timeout overrides so plugin worker exec calls honor the caller's timeout instead of the worker's default. ## Verification - `pnpm typecheck` - `pnpm exec vitest run --no-coverage packages/adapter-utils/src/execution-target-sandbox.test.ts packages/adapter-utils/src/sandbox-install-command.test.ts` - `pnpm exec vitest run --no-coverage server/src/__tests__/plugin-worker-manager.test.ts server/src/__tests__/adapter-registry.test.ts server/src/__tests__/claude-local-adapter-environment.test.ts server/src/__tests__/claude-local-execute.test.ts server/src/__tests__/gemini-local-adapter-environment.test.ts` - `pnpm exec vitest run --no-coverage packages/adapters/codex-local/src/server/test.remote.test.ts packages/adapters/opencode-local/src/server/test.remote.test.ts packages/adapters/codex-local/src/server/codex-args.test.ts packages/adapters/codex-local/src/server/execute.remote.test.ts packages/adapters/gemini-local/src/server/execute.remote.test.ts` All passing locally. ## Risks - Touches shared `adapter-utils` and several `*-local` adapters. The 30-minute default applies only when both (a) the target is `remote+sandbox` and (b) no `timeoutSec` is configured — local + SSH paths are unchanged. New test coverage was added alongside each behavior change to pin the contracts. - Switching OpenCode's install command to the official installer is a behavior change for any operator running OpenCode inside a remote sandbox. Local installs are unaffected (the `SANDBOX_INSTALL_COMMAND` only runs when an adapter is being installed inside a sandbox). - Low risk overall — no migrations, no API surface change. ## Model Used - Provider: Anthropic - Model: Claude Opus 4.7 (1M context) - Capabilities used: extended reasoning, tool use (Read/Edit/Bash/Grep), no code execution beyond local repo commands ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — N/A, no UI change - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
github-actions[bot]
|
6e4fa78d86 |
chore(lockfile): refresh pnpm-lock.yaml (#5668)
Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml. Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com> |
||
|
Devin Foley
|
534aee66ae |
Add cursor_cloud adapter for Cursor SDK + Cloud Agents API v1 (#5664)
## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies
> - There are many adapter types, one per agent-runtime product (Claude,
Codex, OpenCode, Cursor local CLI, etc.)
> - Cursor shipped a public TypeScript SDK on 2026-04-29 that exposes
Cursor's full hosted-agent platform (cloud VMs, harness, MCP, skills,
hooks)
> - Paperclip had no first-class adapter for this — agents that wanted
to use Cursor's managed cloud runtime had to fall back to the local CLI
adapter, which loses the cloud session, streaming, and durable run model
> - This PR adds a new `cursor_cloud` adapter built directly on
`@cursor/sdk`, with Paperclip's heartbeat mapped to Cursor's
durable-agent + per-run model
> - The benefit is that any Paperclip agent can now drive a Cursor cloud
agent across heartbeats with native session reuse, streaming, and
cancellation, while Paperclip remains the source of truth for issue/task
state
## What Changed
- New built-in adapter package `packages/adapters/cursor-cloud` (15
files, ~1.7k LOC) backed by `@cursor/sdk` ^1.0.12
- `src/server/execute.ts` — SDK-first lifecycle: `Agent.create` /
`Agent.resume` / `Agent.getRun` / `agent.send` / `run.stream` /
`run.wait`, with session reuse keyed on the (runtime env type, env name,
repo set) tuple
- `src/server/session.ts` — codec for `cursorAgentId` + `latestRunId` +
repo metadata, persisted in `runtime.sessionParams`
- `src/server/test.ts` — environment probe via `Cursor.me()` and
optional model validation via `Cursor.models.list()`
- `src/ui/parse-stdout.ts` + `src/cli/format-event.ts` — normalize
Cursor SDK message types (`status`, `thinking`, `assistant`, `user`,
`tool_call`, `tool_result`, `result`) into Paperclip transcript events
for the UI and CLI
- Registrations: `packages/shared/src/constants.ts`,
`packages/adapter-utils/src/session-compaction.ts`,
`server/src/adapters/{registry,builtin-adapter-types}.ts`,
`ui/src/adapters/{registry,adapter-display-registry}.ts` +
`ui/src/adapters/cursor-cloud/index.ts`, `cli/src/adapters/registry.ts`,
plus workspace deps in `cli`/`server`/`ui` `package.json`
- `ui/src/components/AgentConfigForm.tsx` — hide local-Cursor
`mode`/thinking-effort field for `cursor_cloud` (different config
surface)
- 11 vitest tests covering execute paths (fresh create, matching-resume,
active-run reattach, non-finished result), session codec round-trip,
transcript parsing, and config building
## Verification
Reviewer steps:
```bash
pnpm install
pnpm --filter @paperclipai/adapter-cursor-cloud typecheck # → clean
pnpm vitest run packages/adapters/cursor-cloud # → 11/11 passing
```
End-to-end check against a real Cursor cloud agent (requires
`CURSOR_API_KEY` and Cursor GitHub-app install on the target repo):
1. Create a `cursor_cloud` agent in Paperclip with `repoUrl` set to the
test repo, `repoStartingRef: main`, and `env.CURSOR_API_KEY` set
2. Trigger a heartbeat → adapter calls `Agent.create({ cloud: { env: {
type: "cloud" }, repos: [...] } })`, streams events, terminates on
`finished`
3. Trigger a second heartbeat → adapter calls `Agent.resume` or
`agent.send` follow-up depending on prior-run state, reusing
`cursorAgentId`
4. The Paperclip UI/CLI transcript reflects Cursor `status` / `thinking`
/ `assistant` events as they stream
5. Cancellation from Paperclip maps to `run.cancel()` or Cloud API v1
`cancelRun` for cross-heartbeat cancellation
A direct-SDK smoke run against a real repo (devinfoley/my_test_project @
main) confirmed: `Cursor.me()` ok → `Agent.create` → `agent.send` →
`run.stream()` (30 events) → terminal status `finished` in ~11s.
## Risks
- **New adapter, additive only.** No existing adapter or registry is
replaced; current `cursor` local-CLI adapter is untouched. Default
behavior of any existing agent is unchanged.
- **External dependency on `@cursor/sdk`.** Cursor's SDK is v1.0.x and
may evolve. Mocked unit tests cover the public surface used here; if the
SDK breaks compatibility we update the adapter independently.
- **Cost/budget.** `cursor_cloud` runs on Cursor's billed cloud VMs;
operators must understand they are spending money outside Paperclip's
budget controls when they enable this adapter. Same shape as other
API-billed adapters.
- **No webhook support in V1.** The SDK already provides
stream/wait/cancel/reattach, so V1 does not require a public callback
URL. If a future use case needs out-of-band wakes, we add a Cloud API v1
webhook bridge as a separate change. This is called out in the issue
plan document.
- **Lockfile.** Per repo policy, `pnpm-lock.yaml` is intentionally not
in this PR — CI's lockfile workflow will update it on merge given the
manifest changes.
## Model Used
- Provider: Anthropic Claude (via Claude Code / Paperclip `claude_local`
adapter)
- Model: `claude-opus-4-7` (Claude Opus 4.7), knowledge cutoff January
2026
- Mode: standard tool-use with extended reasoning
- Context: ~200k token window
- Capabilities used: code generation, multi-file edits, shell/test
execution, GitHub PR workflow
## 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 run tests locally and they pass (11/11 in
`packages/adapters/cursor-cloud`)
- [x] I have added or updated tests where applicable (4 new test files,
11 cases)
- [ ] If this change affects the UI, I have included before/after
screenshots (the only UI change is hiding the local-Cursor mode field on
the `cursor_cloud` adapter — happy to attach a screenshot if the
reviewer wants one)
- [x] I have updated relevant documentation to reflect my changes (issue
plan document supersedes the pre-SDK design; tracked in PAPA-203)
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
---------
Co-authored-by: Paperclip <noreply@paperclip.ing>
|
||
|
Dotta
|
0096b56a1c |
[codex] Add LLM Wiki plugin host support (#5597)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - The plugin system needs host contracts and runtime support before large plugins can integrate cleanly. > - The source branch mixed the LLM Wiki package with supporting host/runtime work, managed plugin skills, root-level storage spaces, and a bookmarks reference plugin. > - [PAP-9173](/PAP/issues/PAP-9173) asked for the current branch to be split by file boundary: plugin package separately from everything else. > - [PAP-9188](/PAP/issues/PAP-9188) clarified that LLM Wiki may have plugin-local spaces, but Paperclip core should not reorganize top-level local storage into spaces. > - Follow-up review clarified that the bookmarks example should not ship in this PR either. > - This pull request contains the non-`packages/plugins/plugin-llm-wiki/` host/runtime work, keeps runtime state under the selected Paperclip instance root, and no longer includes the bookmarks example. ## What Changed - Added/updated plugin host contracts, SDK types, worker RPC plumbing, managed plugin skill support, and related server tests. - Removed the bookmarks example plugin package and its bundled-example/workspace references. - Removed the root-level local spaces CLI/migration surface and restored instance-root runtime defaults for config, db, logs, storage, secrets, workspaces, projects, and adapter homes. - Replaced shared root `space-paths` helpers with `home-paths` helpers for core runtime storage. - Tightened stranded recovery unique-conflict detection so concurrent recovery scans reuse the raced recovery issue when Postgres errors are wrapped. - Kept `packages/plugins/plugin-llm-wiki/` out of this PR diff; plugin-local spaces remain in the stacked plugin-only PR. ## Verification - `pnpm exec vitest run cli/src/__tests__/data-dir.test.ts cli/src/__tests__/home-paths.test.ts cli/src/__tests__/onboard.test.ts packages/shared/src/home-paths.test.ts packages/db/src/runtime-config.test.ts server/src/__tests__/agent-instructions-service.test.ts server/src/__tests__/claude-local-execute.test.ts server/src/__tests__/codex-local-execute.test.ts` - `pnpm exec vitest run packages/db/src/runtime-config.test.ts` - `pnpm exec vitest run server/src/__tests__/plugin-routes-authz.test.ts` - `pnpm --filter @paperclipai/server typecheck` - `pnpm exec vitest run server/src/__tests__/heartbeat-process-recovery.test.ts -t "reuses the raced stranded recovery issue"` skipped locally because embedded Postgres did not initialize on this macOS temp host; the code path was typechecked and is covered by Linux CI. - Boundary check: no core references remain for `PAPERCLIP_SPACE_ID`, `spaces migrate-default`, `@paperclipai/shared/space-paths`, `registerSpacesCommands`, or the removed bookmarks example. - Previous PR head `4f23e034` had green GitHub checks: `verify`, all four serialized server shards, `e2e`, `Canary Dry Run`, `policy`, Snyk, and `Greptile Review`. Current head `582f466d` is re-running checks after the bookmarks deletion. ## Risks - Plugin host changes touch shared runtime paths, so regressions would most likely appear in adapter startup, plugin loading, or local dev path defaults. - Removing the bookmarks example also removes one demonstration of plugin database namespaces plus local-folder persistence; remaining plugin examples still cover bundled example discovery and plugin host flows. - The plugin package itself is intentionally deferred to the stacked plugin-only PR, where LLM Wiki plugin-local spaces live. - Existing installs that tested the transient root-level spaces CLI should stop using it; this PR intentionally removes that unsupported migration surface before merge. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via Codex CLI, tool use and local code execution enabled; context window 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 run tests locally and they pass, except where noted above for host-specific embedded Postgres initialization - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Stacked follow-up: PR #5592 contains only `packages/plugins/plugin-llm-wiki/` and targets this branch. --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
eb12c42009 |
Clarify sandbox provider messaging in company environments (#4902)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Company Environments is the operator-facing seam for choosing where compatible adapters execute work. > - Sandbox provider plugins such as E2B extend that seam, but they are not agent adapters themselves. > - The current Company Environments copy put adapter capability rows and sandbox-provider enablement on the same page without clearly distinguishing the two concepts. > - That made it look like installing the E2B sandbox provider caused a new adapter to appear under adapters. > - This pull request clarifies the UI language so provider plugins are described as backing the Sandbox driver rather than being adapter types. > - The benefit is a more accurate mental model for operators configuring environments and adapters. ## What Changed - Added explicit Company Environments copy stating that installed sandbox providers are not adapter types and instead back the Sandbox driver for compatible adapters. - Renamed the support-matrix column from `Sandbox` to `Sandbox via plugin` to make the provider relationship visible in the table itself. - Extended the existing environments UI test to assert the new clarification text. ## Verification - `pnpm test -- --run ui/src/pages/CompanySettings.test.tsx` Result: could not complete cleanly in this worktree because the checkout is missing its local workspace install links. - Direct Vitest fallback against `ui/src/pages/CompanySettings.test.tsx` Result: failed before test collection on local dependency resolution (`react/jsx-dev-runtime`), so there is no passing automated signal from this checkout. - Manual review Confirm the Company Environments page now says sandbox providers are not adapter types and labels the table column as `Sandbox via plugin`. ## Risks - Low risk. This is a copy-only UI clarification plus a matching test assertion; the main risk is wording drift if the product later decides sandbox providers should be surfaced differently. ## Model Used - OpenAI Codex via the local `codex_local` Paperclip adapter. This run used tool-assisted code editing and shell execution. The exact backend model ID and context window are not exposed in the Paperclip run context for 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 - [ ] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] I will address all Greptile and reviewer comments before requesting merge |
||
|
Devin Foley
|
a72731f118 |
fix: harden release registry verification against npm lag (#4816)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Its release automation publishes canary packages to npm and then validates the published registry state before considering the release healthy > - The failing canary run `25139465018` showed that npm can expose a newly published version through version-specific endpoints before the root package document has fully converged > - That made a successful canary publish look like a failed release because the verifier trusted stale root metadata too early > - This pull request hardens the registry verification path by preferring version-specific manifest checks, retrying convergence-sensitive failures, and distinguishing permanent failures from propagation lag > - While validating that change in CI, a separate teardown race in `heartbeat-stale-queue-invalidation.test.ts` surfaced and was hardened so the PR could pass reliably > - The benefit is that transient npm propagation lag no longer fails a successful canary publish, while genuine registry-state and dependency-integrity failures still stop the release flow promptly ## What Changed - Hardened `scripts/verify-release-registry-state.mjs` so it prefers version-specific manifest resolution over stale root metadata, adds bounded registry-fetch timeouts, and classifies failures as retriable vs non-retriable. - Updated `scripts/release-lib.sh` and `scripts/release.sh` so post-publish registry verification retries only convergence-sensitive failures and reports immediate permanent failures clearly. - Expanded `scripts/verify-release-registry-state.test.mjs` with regression coverage for stale root metadata, fetch timeout behavior, peer dependency range handling, non-retriable canary-latest cases, and related verifier edge cases. - Hardened `server/src/__tests__/heartbeat-stale-queue-invalidation.test.ts` teardown to tolerate the late-comment foreign-key race that CI exposed while validating this branch. ## Verification - `pnpm run test:release-registry` - `node --check scripts/verify-release-registry-state.mjs` - `bash -n scripts/release.sh && bash -n scripts/release-lib.sh` - PR checks passed on head `5c422600fc12acac61f6b7c267a4dc915df622b1`: `policy`, `verify`, `e2e`, `security/snyk`, and `Greptile Review` ## Risks - Low risk. The main behavioral changes are limited to release automation and verifier retry semantics, plus a test-only teardown hardening for a CI race. > I checked [`ROADMAP.md`](ROADMAP.md). This is a narrow release bugfix and does not overlap planned core feature work. ## Model Used - OpenAI Codex via Paperclip `codex_local` with tool use and local code execution enabled. This agent session runs on a GPT-5-class coding model; the exact backend model ID/context window is not exposed by the local adapter runtime. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I have addressed all Greptile and reviewer comments before requesting merge |
||
|
github-actions[bot]
|
a1b2875165 |
chore(lockfile): refresh pnpm-lock.yaml (#5610)
Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml. Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com> |
||
|
Devin Foley
|
2f72cb29ea |
chore: update drizzle-orm to 0.45.2 (#5589)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - The server, DB package, and CLI all rely on the shared Drizzle ORM dependency for core persistence flows. > - A published install was still resolving nested `drizzle-orm@0.38.4`, which left the production package graph behind the intended security update. > - The repo’s documented dependency policy says GitHub Actions owns `pnpm-lock.yaml`, so the correct maintainer workflow is to update dependency manifests in the feature PR and let the lockfile refresh happen separately after merge. > - This pull request therefore keeps the Drizzle upgrade to the package manifests only and leaves lockfile regeneration to the existing `Refresh Lockfile` automation. ## What Changed - Updated `drizzle-orm` dependency declarations in `cli/package.json`, `packages/db/package.json`, and `server/package.json` from `0.38.4` / `^0.38.4` to `0.45.2` / `^0.45.2`. - Re-verified the packed `@paperclipai/db` and `@paperclipai/server` publish payloads to confirm their generated `package.json` files advertise `drizzle-orm ^0.45.2`. - Removed the temporary lockfile/CI follow-up commits so the branch now matches the intended manifest-only protocol. ## Verification - `pnpm list drizzle-orm -r --depth 0` - `pnpm exec vitest run packages/db/src/client.test.ts server/src/__tests__/issues-service.test.ts` - `pnpm run test:release-registry` - Packed `@paperclipai/db` and `@paperclipai/server` locally and inspected the tarball `package.json` files to confirm they advertise `drizzle-orm ^0.45.2`. ## Risks - Low to moderate risk: the runtime code paths are unchanged, but downstream lockfile refresh now depends on the existing post-merge GitHub automation working as documented. - A separate packaging/versioning issue around unpublished `@paperclipai/plugin-sdk@1.0.0` showed up during a raw local tarball install experiment; that is called out for reviewers but is not part of this Drizzle bump. ## Model Used - OpenAI Codex via the `codex_local` adapter, using a GPT-5-based coding agent with terminal tool use and code execution. The adapter does not expose a public exact model ID or context-window value in this environment. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge |
||
|
Dotta
|
e3af7aa489 |
Add shared sidebar section controls (#5585)
## Thinking Path > - Paperclip is the control plane for AI-agent companies. > - The board UI sidebar is one of the main ways operators scan active agents and projects. > - Agents and projects had duplicated section header behavior, which made collapse controls, add actions, and future section menus harder to keep consistent. > - Operators also need lightweight ways to switch between their curated sidebar order and common scan orders like alphabetical or recent activity. > - This pull request introduces a shared sidebar section header and uses it for the Agents and Projects sidebar sections. > - The benefit is a more consistent sidebar surface with reusable header controls and persisted sort modes without losing the existing drag-ordered Top view. ## What Changed - Added a reusable `SidebarSection` component that supports collapsible content, header actions, and section dropdown menus. - Updated the Agents sidebar section to use the shared header and add persisted `Top`, `Alphabetical`, and `Recent` sort modes. - Updated the Projects sidebar section to use the shared header and add persisted `Top`, `Alphabetical`, and `Recent` sort modes. - Added local-storage helpers and cross-tab update events for agent/project sidebar sort preferences. - Added focused component coverage for the shared section behavior and the updated Agents/Projects sidebar ordering paths. ## Verification - `pnpm run preflight:workspace-links && pnpm exec vitest run ui/src/components/SidebarSection.test.tsx ui/src/components/SidebarProjects.test.tsx ui/src/components/SidebarAgents.test.tsx` - 3 test files passed - 18 tests passed ## Risks - Low-to-moderate UI risk: this changes sidebar section header interactions and adds persisted client-side sort preferences. - Drag ordering is intentionally limited to `Top` mode; non-top modes render sorted lists and do not persist drag order changes. - No database migrations or API contract changes. > 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 coding agent, GPT-5-based model, tool-use enabled; exact hosted model build/context-window identifier was 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
433dfed33d |
Enable CI publish for plugin-daytona (#5586)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The release pipeline gates new public packages behind a bootstrap policy: `scripts/check-release-package-bootstrap.mjs` requires every package marked `publishFromCi: true` in `scripts/release-package-manifest.json` to already exist on npm > - PR #5580 added the new Daytona sandbox provider plugin but had to land with `publishFromCi: false` because the package had never been published, so CI's release plan would have failed bootstrap validation otherwise > - Now that `@paperclipai/plugin-daytona` has been bootstrap-published to npm by hand, the temporary `false` flag is the only thing keeping it out of the standard CI publish flow > - This pull request flips the Daytona entry to `publishFromCi: true`, matching every other release-enabled package in the manifest > - The benefit is that future tagged releases will publish the Daytona plugin automatically alongside the rest of the monorepo's public packages ## What Changed - Single-line flip in `scripts/release-package-manifest.json`: `@paperclipai/plugin-daytona` is now `publishFromCi: true` ## Verification - `node ./scripts/release-package-map.mjs check` → `Release package manifest OK: 19 enabled for CI publish, 0 disabled pending bootstrap` (was 18 + 1) - `node ./scripts/check-release-package-bootstrap.mjs scripts/release-package-manifest.json` against `origin/master` → `Release bootstrap OK for changed manifests: @paperclipai/plugin-daytona`, confirming npm sees the bootstrap-published package - No code changes; no tests required beyond the existing manifest validators ## Risks - Low risk. Only effect is that the next release run will include `@paperclipai/plugin-daytona` in its publish set - If the npm bootstrap was incomplete, CI's bootstrap check will fail loudly before any release tag goes out — same safety net the policy is designed to provide ## Model Used - Claude Opus 4.7 (`claude-opus-4-7`), extended thinking, tool use enabled ## 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 run tests locally and they pass - [ ] I have added or updated tests where applicable (N/A — manifest-only flag flip, covered by existing validators) - [ ] If this change affects the UI, I have included before/after screenshots (N/A — release config) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
778e775c35 |
Add secrets provider vaults and remote import (#5429)
## Thinking Path > - Paperclip orchestrates AI-agent companies and needs secrets handling to work across local development, hosted operators, and governed agent execution. > - The affected subsystem is the company-scoped secrets control plane: database schema, server services/routes, CLI workflows, and the Secrets settings UI. > - The gap was that secrets were local-only and operators could not manage provider vaults or import existing remote references without exposing plaintext. > - This branch adds provider vault configuration plus an AWS Secrets Manager remote-import path while preserving company boundaries, binding context, and audit trails. > - I kept the PR to a single branch PR, removed unrelated lockfile/package drift, rebased the full branch onto the current `public-gh/master`, and addressed fresh Greptile findings. > - The benefit is a reviewable implementation of provider-backed secrets with focused tests covering provider selection, import conflicts, deleted secret reuse, rotation guards, and AWS signing behavior. ## What Changed - Added provider vault support for company secrets, including provider config storage, default vault handling, health checks, binding usage, access events, and remote import preview/commit. - Added an AWS Secrets Manager provider using SigV4 request signing, bounded request timeouts, namespace guardrails, cached runtime credential resolution, and external-reference linking without plaintext reads. - Added Secrets UI surfaces for vault management and remote import, plus CLI/API documentation for setup and operations. - Stabilized routine webhook secret binding paths and SSH environment-driver fixture bindings discovered during verification. - Addressed Greptile and CI findings: no lockfile/package drift, monotonic migration metadata, disabled-vault default races, soft-deleted secret hiding/recreate behavior, remove behavior with disabled vaults, soft-deleted external-reference re-import, non-active rotation guards, managed-secret soft deletion through PATCH, and per-call AWS SDK credential client churn. - Rebased this branch onto `public-gh/master` at `0e1a5828` and force-pushed with lease to keep this as the single PR for the branch. ## Verification - `git fetch public-gh master` - `git rebase public-gh/master` - `git diff --name-only public-gh/master...HEAD | grep '^pnpm-lock\.yaml$' || true` confirmed `pnpm-lock.yaml` is not in the PR diff. - Confirmed migration ordering: master ends at `0081_optimal_dormammu`; this PR adds `0082_dry_vision` and `0083_company_secret_provider_configs`. - Inspected migrations for repeat safety: new tables/indexes use `IF NOT EXISTS`; foreign keys are guarded by `DO $$ ... IF NOT EXISTS`; column additions use `ADD COLUMN IF NOT EXISTS`. - `pnpm -r typecheck` passed before the Greptile follow-up commits. - `pnpm test:run` ran the full stable Vitest path before the Greptile follow-up commits; it completed with 3 timing-related failures under parallel load: `codex-local-execute.test.ts`, `cursor-local-execute.test.ts`, and `environment-service.test.ts`. - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/codex-local-execute.test.ts src/__tests__/cursor-local-execute.test.ts src/__tests__/environment-service.test.ts` passed on targeted rerun (`24/24`). - `pnpm build` passed before the Greptile follow-up commits. Vite reported existing chunk-size/dynamic-import warnings. - After Greptile follow-up commits: `pnpm --filter @paperclipai/server exec vitest run src/__tests__/secrets-service.test.ts` passed (`26/26`). - After Greptile follow-up commits: `pnpm --filter @paperclipai/server exec vitest run src/__tests__/aws-secrets-manager-provider.test.ts src/__tests__/secrets-service.test.ts` passed (`39/39`). - After Greptile follow-up commits: `pnpm --filter @paperclipai/server typecheck` passed. - Captured Storybook screenshots from `ui/storybook-static` for visual review. - Latest PR checks on `5ca3a5cf`: `policy`, serialized server suites 1/4-4/4, `Canary Dry Run`, `e2e`, `security/snyk`, and `Greptile Review` pass; aggregate `verify` is still registering the completed child checks. - Greptile review loop continued through the latest requested pass; all Greptile review threads are resolved and the latest `Greptile Review` check on `5ca3a5cf` passed with 0 comments added. ## Screenshots Before: the provider-vault and remote-import surfaces did not exist on `master`; these are after-state screenshots from the Storybook fixtures.    ## Risks - Migration risk: this adds new secret provider tables and extends existing secret rows. The migrations were checked for monotonic ordering and idempotent guards, but reviewers should still inspect upgrade behavior carefully. - Provider risk: AWS support uses direct SigV4 requests. Automated tests cover signing, request timeouts, vault-config selection, namespace guardrails, pending-version archival, sanitized provider errors, and service-level cleanup paths. A real-vault AWS smoke test remains deployment validation for an operator with AWS credentials rather than an unverified merge blocker in this local branch. - UI risk: the Secrets page and import dialog are large new surfaces; screenshots are included above for reviewer inspection. - Verification risk: the full local stable test command hit parallel-load timing failures, although the exact failed files passed when rerun directly. - Operational risk: remote import intentionally avoids plaintext reads; operators must understand that imported external references resolve at runtime and may fail if AWS permissions change. > 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, GPT-5 coding agent with local shell/tool use in the Paperclip worktree. Exact context-window size was not exposed by the runtime. ## 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 - [ ] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
Devin Foley
|
06e6ee25cd |
Add Daytona sandbox provider plugin (#5580)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Agents need isolated sandbox environments to execute work safely; Paperclip already supports E2B as a sandbox provider plugin > - Users want to use Daytona (https://www.daytona.io/) as an alternative sandbox backend, but no plugin existed for it > - Without a Daytona plugin, teams that prefer Daytona's pricing/regions/runtime can't run Paperclip agents on it > - This pull request adds a `@paperclip/sandbox-provider-daytona` plugin that mirrors the existing E2B plugin shape and wires up Daytona's `@daytonaio/sdk` for sandbox lifecycle, command execution, and shell detection > - The benefit is that operators can pick Daytona as a first-class sandbox provider without touching core code, broadening Paperclip's runtime options ## What Changed - New plugin package `packages/plugins/sandbox-providers/daytona` with manifest, worker entry, and provider implementation backed by `@daytonaio/sdk` - Implements sandbox create/destroy/exec/upload/download lifecycle, shell command detection, and config/env wiring consistent with the E2B plugin - Adds unit tests under `src/plugin.test.ts` and a README documenting setup and the `DAYTONA_API_KEY` requirement - Minor adjustments in `scripts/paperclip-issue-update.sh`, `packages/shared/src/issue-thread-interactions.test.ts`, and `packages/shared/src/validators/issue.ts` to support the integration ## Verification - Re-ran the full sandbox provider matrix on the QA Paperclip instance using Daytona as the runtime — all 6 adapters executed inside the Daytona sandbox with zero `environmentExecute` timeouts - 5/6 adapters pass cleanly (or with informational warns); the only failure is `codex_local`, which is an OpenAI quota/billing issue unrelated to Daytona - `pnpm --filter @paperclip/sandbox-provider-daytona test` runs the plugin unit tests ## Risks - New optional plugin; no behavior change for users who don't enable it - Requires `DAYTONA_API_KEY` for runtime use — documented in the plugin README - Daytona SDK is a new external dependency; tracked in the plugin's own package.json so it doesn't affect the core install footprint ## Model Used - Claude Opus 4.7 (`claude-opus-4-7`), extended thinking, tool use enabled ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots (N/A — backend plugin) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Devin Foley
|
f784d8d90e |
Retry canary registry verification (#5579)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, and the release pipeline is part of keeping that control plane shippable. > - The relevant subsystem here is the release automation in `scripts/release.sh`, which publishes canary builds and then verifies npm registry state. > - The failing CI run showed a successful publish followed by an immediate registry-state verification failure while npm dist-tag metadata was still propagating. > - That made the canary job flaky even when the publish itself had succeeded, which is the wrong failure mode for release automation. > - This pull request adds bounded retries around the post-publish registry-state verification step instead of failing on the first stale read. > - The benefit is that canary releases tolerate transient npm propagation lag while still failing clearly if registry metadata never converges. ## What Changed - Wrapped the post-publish `verify-release-registry-state.mjs` call in a bounded retry loop inside `scripts/release.sh`. - Reused the existing publish verification retry defaults and added optional overrides via `NPM_REGISTRY_STATE_VERIFY_ATTEMPTS` and `NPM_REGISTRY_STATE_VERIFY_DELAY_SECONDS` for dist-tag-specific tuning. ## Verification - `bash -n scripts/release.sh` - CI will also exercise the release path via the existing `Canary Dry Run` workflow job in `.github/workflows/pr.yml`. ## Risks - Low risk. The main behavioral change is that a genuinely broken registry-state verification can now wait through the configured retry window before failing. > 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 local agent, GPT-5-based Codex runtime in Paperclip with tool use and shell execution. The exact backend model ID/context window is not surfaced in this local heartbeat environment. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge |
