mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-25 17:45:53 +01:00
8a7fcc94db0b8a75bb3f17dbe470fb7d458262e5
2878
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dotta
|
8a7fcc94db | Accept Hermes stop run creation 202 | ||
|
Dotta
|
0ad052ad17 | Poll Hermes run after quiet SSE probe | ||
|
Dotta
|
e64d0fe38c | Use OpenRouter GLM config for Hermes smoke | ||
|
Dotta
|
8838670ce5 | Pass Hermes provider secrets into smoke container | ||
|
Dotta
|
e4f1dee8e5 | Accept Hermes run creation 202 | ||
|
Dotta
|
4ecb33e607 | Install Hermes gateway API dependency | ||
|
Dotta
|
d2e65c0ba1 | Fix Hermes smoke bind mount permissions | ||
|
DottaandPaperclip
|
b025345c71 |
Remove Hermes Python bin shims before npm bridge
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
ddf5d7818c |
Fix Hermes gateway smoke image binary conflict
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
2066e83444 |
Build plugin SDK before smoke server start
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
e24eb1b8cd |
Allow smoke workflow to refresh lockfile
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
5f5b5fadab |
Fix Hermes smoke workflow temp paths
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
65718a8837 |
Run Hermes gateway smoke on Docker runner
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
c8e4d58172 |
Add Hermes gateway smoke docs and validation
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
738f9b28e1 |
Add Hermes gateway Docker e2e smoke
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
88119ef815 |
Make Hermes adapters built in
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
bce5b6e5f9 |
Initialize Hermes smoke redaction state
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
61b21059c9 | Add Hermes gateway smoke harness | ||
|
DottaandPaperclip
|
6f21eae0a4 |
Secretize Hermes join defaults
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
73e5bd8f4e | PAP-11957 scope Hermes task bridge credentials | ||
|
DottaandPaperclip
|
f0e2bffe42 |
Harden Hermes gateway transport and secrets
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
401da17d37 |
Tighten Hermes gateway onboarding prompt note
Restructure the inline add-agent prompt note into scannable bullets and add the missing agentDefaultsPayload.apiKey field so the prompt matches the onboarding.txt/doc payload. Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
ed86920ffa |
Add Hermes gateway adapter plugin
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
f565280dff |
Add Hermes Paperclip task bridge
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
802245c94b |
Add Hermes gateway onboarding docs
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
594438c931 |
Remove built-in Hermes adapter wiring
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
3866c9773f | Add Hermes prompt rendering regression tests | ||
|
Dotta
|
8032c1364b | Optimize Hermes wake context prompt | ||
|
DottaandPaperclip
|
fb11ed07fb |
Fix Hermes adapter release package metadata
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
133c080b69 |
Align Hermes adapter package version
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
59003208c9 |
Enroll Hermes adapter in release publishing
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
23a0a116d5 |
Add Hermes adapter workspace package
Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|
Dotta
|
1a3e398107 |
Add bundled Paperclip capsules skill
Add the bundled paperclip-capsules skill, durable generator workflow references, catalog manifest updates, and shipped catalog coverage.canary/v2026.626.0-canary.5 |
||
|
Dotta
|
8f7282066e |
Add workspace file downloads
Add first-class workspace file downloads, broader attachment content-type support, and the stream-lifetime limiter fix from PR review.canary/v2026.626.0-canary.4 |
||
|
Devin Foley
|
fdb8b5678b |
fix(ui): restore main-content scroll position on browser back/forward (#8636)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The web UI (`ui/`) renders inside a single persistent shell (`Layout`) whose `#main-content` element is the scroll container for every route > - Because that scroll container survives route changes, browser back/forward (a history `POP`) lands on the previous page with the scroll offset of the page you just left > - Concretely: scroll deep into an issue detail, hit browser back, and the inbox renders scrolled to the issue-detail offset instead of where you left off — making it hard to find your place > - The app already reset scroll for forward (`PUSH`) navigation but deliberately did nothing on `POP`, so nothing restored the prior position > - This pull request records each history entry's scroll offset as the user scrolls and restores it on `POP`, while keeping the existing reset-to-top behavior for `PUSH`/`REPLACE` > - The benefit is that back/forward returns you to the exact place you were, so the inbox (and any scrolled page) keeps your reading position ## Linked Issues or Issue Description No public GitHub issue — describing the bug inline following the bug report template. **What happened** From the inbox, open an issue, scroll down within the issue detail, then press the browser Back button. The inbox is restored at the wrong scroll position — it shows the Y offset from the issue-detail page rather than the position you had in the inbox. **Expected behavior** Browser back/forward returns the page to the scroll position it had when you left it. **Steps to reproduce** 1. Open the inbox and scroll to a known position partway down the list. 2. Click into an issue. 3. Scroll down within the issue detail. 4. Press the browser Back button to return to the inbox. 5. Observe the inbox is scrolled to the issue-detail offset instead of where you left off. **Deployment mode** Web UI (`ui/`), any deployment — client-side scroll behavior only. Root cause: `#main-content` is a single scroll container that stays mounted across route changes. Scroll was only reset on forward (`PUSH`) navigation and left untouched on `POP`, so the stale offset from the outgoing page persisted onto the page being returned to. ## What Changed - Added `NavigationScrollMemory` (`ui/src/lib/navigation-scroll.ts`): a per-history-key map of `#main-content` scroll offsets, clamped to `>= 0`. - Added `applyMainContentScrollTop` helper to restore a saved offset onto the main content element (null-safe). - In `Layout` (`ui/src/components/Layout.tsx`): continuously record the active history entry's scroll offset on scroll, and on `POP` navigation restore the remembered offset (re-applying on the next animation frame so a late-laying-out cached page doesn't clamp the offset to a shorter interim height). Forward `PUSH`/`REPLACE` keeps the existing reset-to-top behavior. - Added unit tests covering the remember/recall logic and the restore helper. ## Verification - `ui` unit tests pass, including the new `navigation-scroll` cases (remember/recall per key, clamping, and DOM restore). - TypeScript clean on the changed files. - Manual: inbox → open issue → scroll down → browser Back returns the inbox to its previous scroll position; forward navigation still resets to top. ## Risks Low risk. Scoped to client-side scroll restoration in the web UI; no API, schema, or migration changes. The only behavioral change is that `POP` navigation now restores a saved offset instead of leaving the container untouched; `PUSH`/`REPLACE` behavior is unchanged. Memory is per-session and bounded by visited history keys. ## Model Used Claude (Anthropic), Opus-class model via Paperclip's `claude_local` adapter, with extended thinking and tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting mergecanary/v2026.626.0-canary.3 |
||
|
DottaandPaperclip
|
8e21e31a1a |
Fix UI detail regressions (#8613)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The board UI needs to render issue details, comments, properties, and rich external object labels clearly during normal operator workflows. > - Three small UI regressions made those workflows harder to scan: rich object URLs could show weak labels, interrupting comments could briefly flash in the wrong state, and watchdog labels could overflow the properties panel. > - These are related quality fixes in the same UI surface, with focused regression coverage for each behavior. > - This pull request groups the fixes so they go through normal review instead of bypassing CI. > - The benefit is a quieter, more predictable issue detail experience for board operators. ## Linked Issues or Issue Description No public GitHub issue was found for these regressions after searching related PRs and issues. ### Pre-submission checklist - Existing open and closed GitHub issues and PRs were searched for duplicates. - The fixes are based on current `master` behavior. - The regressions originate in Paperclip board UI code, not an adapter, API provider, or local configuration. ### What happened? In the board UI, three issue-detail regressions made normal review workflows harder to scan: - URL-rich external objects could fall back to a weak generic label instead of showing a useful URL label. - An interrupting issue comment could briefly flash through the wrong state while issue run data refreshed. - Long watchdog property instructions could truncate or overflow instead of wrapping inside the properties panel. ### Expected behavior - URL-rich external objects should surface a clear URL label. - Interrupting comments should stay visually stable while live run state refreshes. - Long watchdog property values should wrap within the available properties panel width. ### Steps to reproduce 1. Open an issue detail view that includes URL-rich external object metadata, an interrupting run/comment state, or long watchdog instructions. 2. Observe the rendered issue detail thread and properties panel. 3. Compare the rendered label, comment state, and watchdog row wrapping against the expected stable/readable behavior above. ### Paperclip version or commit Current `master`, fixed by this PR branch at `1c763001c9a16fa6cf3faad6f58a83c4b202c928`. ### Deployment mode Local dev (`pnpm dev`) / board UI. ### Installation method Built from source (`pnpm dev` / `pnpm build`). ### Agent adapter(s) involved Not adapter-specific (core board UI bug). ### Database mode Not database-related. ### Access context Board operator UI. ### Relevant logs or output Not applicable. ### Relevant config Not applicable. ### Additional context The PR includes focused regression tests for all three behaviors. Browser-visible before/after evidence for the watchdog wrapping change was posted in https://github.com/paperclipai/paperclip/pull/8613#issuecomment-4794863305. ### Privacy checklist - All pasted output was reviewed for sensitive data; this PR body contains no private config, logs, or internal instance links. ## What Changed - Prefer direct URLs as rich object labels when rendering external object metadata. - Keep interrupting issue comments from flashing through the wrong thread state while issue chat data is refreshing. - Allow watchdog property labels to wrap cleanly inside the issue properties panel. - Added focused regression coverage for the external object helper, issue detail interrupt behavior, and watchdog property wrapping. ## Verification - `pnpm exec vitest run ui/src/lib/external-objects.test.ts ui/src/lib/issue-chat-messages.test.ts ui/src/components/IssueProperties.test.tsx ui/src/pages/IssueDetail.test.tsx` ## Risks Low risk. The changes are scoped to UI rendering/state handling and add regression coverage for the touched behavior. No database, API, workflow, lockfile, or migration changes 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 using GPT-5 (`gpt-5`) with repository shell/tool access. The changes were prepared by an AI coding agent with local command execution for git inspection and focused Vitest verification. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.626.0-canary.2 |
||
|
DottaandPaperclip
|
569b7affc4 |
[codex] Add bounded workspace overview (#8627)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The execution workspace subsystem powers project and workspace views by listing runtime state, branch metadata, issue links, and status summaries. > - The existing workspace views relied on broad list data that can grow expensive as a company accumulates many workspaces and linked issues. > - That makes the Workspaces page and project workspace cards slower than necessary because the UI does not always need the full workspace detail payload up front. > - This pull request adds a bounded overview contract for workspace listings and moves the relevant UI surfaces to that cheaper path. > - The benefit is faster workspace loading while preserving detail fetches for pages that actually need full workspace data. ## Linked Issues or Issue Description No public GitHub issue exists for this change. Inline bug report follows the repository bug template. ### What happened? Workspace index-style screens can load too much execution workspace detail before the user asks for it. Several UI surfaces used fuller workspace data paths for summary displays, which can make workspace loading slower as workspace history grows. ### Expected behavior Overview screens should request a bounded summary payload, while detail screens should keep using the full workspace detail endpoint. ### Steps to reproduce 1. Run Paperclip from source with enough execution workspace history to make workspace lists non-trivial. 2. Open the Workspaces page or a project workspace summary card. 3. Observe that summary UI needs only bounded workspace metadata but can depend on broader workspace payloads. ### Paperclip version or commit `master` at the time this branch was prepared. ### Deployment mode Local dev (`pnpm dev`) ## What Changed - Added shared types, validators, and path constants for bounded execution workspace overviews. - Added server service and route support for overview queries with bounded linked issue/runtime metadata. - Updated workspace overview UI API calls, query keys, breadcrumbs, quicklooks, close dialogs, project summaries, and detail links to consume the cheaper overview shape where appropriate. - Added regression coverage for the new server route/service behavior and the UI overview consumers. - Registered the new workspace overview route in the generated OpenAPI spec. - Kept overview totals aligned with the project join and preserved project slug links in workspace headers. ## Verification - `pnpm exec vitest run server/src/__tests__/execution-workspaces-service.test.ts server/src/__tests__/execution-workspaces-routes.test.ts ui/src/api/execution-workspaces.test.ts ui/src/components/ProjectWorkspaceSummaryCard.test.tsx ui/src/pages/Workspaces.test.tsx` - `pnpm --filter @paperclipai/shared typecheck && pnpm --filter @paperclipai/server typecheck && pnpm --filter @paperclipai/ui typecheck` - `pnpm exec vitest run server/src/__tests__/openapi-routes.test.ts server/src/__tests__/execution-workspaces-routes.test.ts server/src/__tests__/execution-workspaces-service.test.ts` - `pnpm test:run:serialized -- --shard-index 1 --shard-count 4` ## Risks Low to medium risk. The change introduces a new overview contract across shared/server/ui layers, so the main risk is a mismatch between summary and detail payload expectations. The added route/service/UI tests cover the intended split, and full detail pages continue using the detail path. > 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 repository tool use and local command execution. Exact served model identifier and context window were not exposed in this session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.626.0-canary.1 |
||
|
LeonSGP
|
3d7a4f12f9 |
fix(claude-local): use direct 4.5 model aliases (#3800)
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - The `claude_local` adapter is the control-plane surface that turns Paperclip agent settings into concrete Claude CLI invocations. > - Issue #3777 reports that selecting Claude Haiku 4.5 from the Paperclip UI causes Claude Code to request `claude-haiku-4-5-20251001`, which some enterprise-scoped keys are not allowed to access. > - In the current adapter model list, the direct Anthropic 4.5 entries are version-pinned IDs, unlike the 4.6 entries which already use the stable short aliases. > - This pull request switches the direct 4.5 `claude_local` model options to the short aliases Claude Code account access expects, while leaving Bedrock-native IDs unchanged in the Bedrock-specific model list. > - The benefit is that selecting Claude Sonnet 4.5 or Claude Haiku 4.5 from Paperclip no longer forces the CLI onto a more restrictive versioned direct model name. ## What Changed - Updated the direct `claude_local` adapter model list to use `claude-sonnet-4-5` instead of `claude-sonnet-4-5-20250929`. - Updated the direct `claude_local` adapter model list to use `claude-haiku-4-5` instead of `claude-haiku-4-5-20251001`. - Left the Bedrock-specific model IDs in `src/server/models.ts` unchanged so AWS Bedrock routing still uses region-qualified native IDs. ## Verification - `pnpm install --frozen-lockfile` - `pnpm --filter @paperclipai/adapter-claude-local typecheck` - Confirmed the only source change is `packages/adapters/claude-local/src/index.ts`. ## Risks - Low risk. This only changes the direct `claude_local` model IDs advertised by Paperclip for the two 4.5 options. - Bedrock behavior is unchanged because the Bedrock-native identifiers are defined separately and were not modified in this PR. - Existing 4.6 model options are untouched. ## Model Used - OpenAI Codex on a GPT-5-class coding model with terminal tool use and local code execution in 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 run tests locally and they pass - [ ] 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 Fixes #3777canary/v2026.626.0-canary.0 |
||
|
Devin FoleyandPaperclip
|
5170a9d35d |
Test cheap model during agent config check (#8632)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent configuration includes adapter model settings and optional cheap model profiles used by runtime lanes. > - The agent configuration screen already exposes a Test action for adapter environment checks. > - When a cheap model profile is configured, that Test action only exercised the primary model configuration. > - That left users able to save a cheap model profile that had not been validated by the same configuration test flow. > - This pull request makes the Test action probe both the primary model and the configured cheap model. > - The benefit is earlier feedback when the cheap model is unavailable or misconfigured. ## Linked Issues or Issue Description No exact public issue found. Problem description: - What happened: the agent configuration Test action validated the primary adapter model but did not validate an enabled cheap model profile. - Expected behavior: when a cheap model is configured and enabled, the Test action should also test that cheap model using the same environment selection. - Steps to reproduce: configure an agent with a primary model and enabled cheap model profile, then click Test in the agent configuration UI. - Paperclip version/commit: current `master` at PR creation. - Deployment mode: local development UI behavior. Related public context found during GitHub search: - #4881 added cheap model profiles for local adapters. - #6534 is related cheap-primary-model preservation work. - #6956 tracks broader agent configuration settings exposure. GitHub searches performed: - `cheap model config test` - `AgentConfigForm cheap model` - `modelProfiles cheap` - `adapter environment cheap model` ## What Changed - Updated `AgentConfigForm` so the adapter environment Test action runs the primary model check first. - Added a second cheap model check when the cheap profile is enabled and resolves to a model. - Built the cheap test payload from the resolved cheap profile config instead of a model-only override, preserving adapter-default and saved cheap-profile fields. - Merged the individual results into a single labeled result so the UI can show both outcomes together. - Preserved request/API failures so they still surface through the existing error UI instead of becoming synthetic adapter checks. - Added render coverage asserting both primary and cheap test calls, non-model cheap-profile fields, and request failure handling. ## Verification - `git diff origin/master...HEAD | rg -n "(API[_-]?KEY|SECRET|TOKEN|PASSWORD|PRIVATE[_-]?KEY|BEGIN RSA|BEGIN OPENSSH|Bearer [A-Za-z0-9._-]+|ghp_[A-Za-z0-9_]+|sk-[A-Za-z0-9]+|AIza[0-9A-Za-z_-]+|OPENAI_API_KEY|ANTHROPIC_API_KEY)" || true` produced no matches. - `git diff --check origin/master...HEAD` - `pnpm --filter @paperclipai/ui exec vitest run src/components/AgentConfigForm.render.test.tsx --reporter=dot` - `pnpm --filter @paperclipai/ui typecheck` - GitHub PR checks on head `3d9ba15d2` are green, including Build, Typecheck + Release Registry, General tests, serialized server suites, e2e, Canary Dry Run, security scans, and policy/review checks. - Greptile Review passed on head `3d9ba15d2`; all review threads are resolved. ## Risks Low risk. The change is limited to the agent configuration UI test action and its render test. The cheap-model probe now preserves adapter-default and saved cheap-profile fields, matching the runtime merge order more closely. The main residual risk is adapter-specific UI coverage for cheap-profile fields that are stored but not directly editable in this form. ## Model Used OpenAI GPT-5 Codex via the Codex local agent environment, with terminal/tool use for repository inspection, implementation, GitHub CLI operations, and local verification. Exact context window 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 - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.7 |
||
|
Devin FoleyandPaperclip
|
f90ea4dae4 |
Fix top-level secret ref binding sync (#8630)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Instance environments can store provider configuration fields as Paperclip secret references > - Environment save uses secret binding sync to keep persisted config refs aligned with `company_secret_bindings` > - Top-level secret-ref fields such as `apiKey` were not deleted during sync because the cleanup only matched child paths like `apiKey.*` > - Re-saving an environment with the same top-level secret ref could therefore hit the target/path unique constraint and return a 500 > - This pull request makes the sync cleanup include the exact top-level config path before reinserting current refs > - The benefit is that saved environment provider configs can be edited repeatedly without duplicate binding failures ## Linked Issues or Issue Description No public GitHub issue found in duplicate search for this exact environment secret-binding failure. ### Bug report #### Pre-submission checklist - I searched existing open and closed issues and this is not a duplicate. - I can reproduce this on the current `master` lineage. - I confirmed the error originates in Paperclip secret-binding sync, not the sandbox provider itself. #### What happened? Saving an instance environment whose provider config contains a top-level secret-ref field can fail with a duplicate key error on `company_secret_bindings_target_path_uq`. #### Expected behavior Saving the same environment config repeatedly should update/sync bindings idempotently. #### Steps to reproduce 1. Create or edit an instance environment with a provider config that has a top-level secret-ref field such as `apiKey`. 2. Save the environment. 3. Save the environment again without moving that field under a nested object. 4. The second save can attempt to insert a duplicate binding for the same target/path. #### Paperclip version or commit Observed on local dev from current `master` lineage before this fix. #### Deployment mode Local dev (pnpm dev), authenticated private mode. #### Installation method Built from source (pnpm dev / pnpm build). #### Agent adapter(s) involved Not adapter-specific (core bug). #### Database mode Embedded local Postgres. #### Access context Board (human operator) environment settings save. #### Relevant logs or output The server returned a 500 after Postgres rejected a duplicate `company_secret_bindings` row for the same environment target and `apiKey` config path. Secret values and local paths are intentionally omitted. #### Privacy checklist I reviewed the PR description for private instance links, local paths, API keys, tokens, and company-specific secrets. ## What Changed - Updated `syncSecretRefsForTarget()` so prefix cleanup removes both the exact top-level config path and nested child paths. - Added a regression test that syncs an environment top-level `apiKey` secret ref repeatedly, then replaces it and verifies only one binding remains. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/secrets-service.test.ts` - `pnpm --filter @paperclipai/server typecheck` - `git diff --check` - Local diff scan for internal issue links, local paths, bearer/session tokens, and obvious secret literals returned no matches. - GitHub duplicate searches for related environment secret-binding issues/PRs returned no matches. ## Risks Low risk. The change only broadens the existing target/path cleanup used before reinserting secret refs. It preserves the existing child-path cleanup behavior and adds the missing exact-path case. ## Model Used OpenAI GPT-5 Codex via the `codex_local` Paperclip adapter. Tool-using coding-agent session with shell, git, and repository-edit capabilities. 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 - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.6 |
||
|
DottaandPaperclip
|
841742fc1a |
[codex] Graduate experimental conference room defaults (#8628)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The board UI has been graduating experimental conference-room task experiences into the default issue and onboarding flows > - Several task UI improvements were still coupled to the Conference Room Chat experimental flag even though they are useful outside chat itself > - That coupling meant disabling chat also reverted unrelated defaults such as work-mode labels, task status colors, team creation copy, and the graduated issue thread > - This pull request keeps chat-specific gating scoped to chat while making the graduated task UI the default experience > - The benefit is that operators can use the newer task workflows without needing to enable the separate chat experiment ## Linked Issues or Issue Description No public GitHub issue exists for this exact change. ### Problem or motivation The Conference Room Chat experimental flag was controlling unrelated task UI defaults, which made non-chat workflows regress when chat was disabled. ### Proposed solution Remove that flag from task-thread, work-mode, onboarding, status, and team-creation presentation paths while leaving chat-specific behavior separately gated. ### Alternatives considered Keeping the flag as a broad umbrella until chat graduates would avoid a behavior change, but it keeps unrelated UI improvements hidden behind the wrong capability switch. ### Roadmap alignment Checked `ROADMAP.md`; this is focused graduation/polish for existing UI surfaces rather than a new roadmap-level core feature. Related search: - Searched open PRs and issues for `conference room chat experimental flag`: no matches. - Searched open PRs and issues for `graduated issue thread`: no matches. ## What Changed - Removes Conference Room Chat flag branching from task-thread rendering, work-mode labels, task status colors, and team creation copy. - Makes the onboarding completion path create/reuse an onboarding project, create the first assigned task, and send the user to the dashboard instead of chat. - Deletes the legacy onboarding wizard and classic task-thread files now that the graduated flow is the default. - Updates focused UI tests and affected E2E specs for the default task experience. - Adds a user-visible onboarding error if restored state is missing the company or agent required for launch. ## Verification - `pnpm run preflight:workspace-links && pnpm exec vitest run ui/src/components/NewIssueDialog.test.tsx ui/src/components/OnboardingWizardVariant.test.tsx ui/src/components/RunChatSurface.test.tsx ui/src/components/SidebarCompanyMenu.test.tsx ui/src/components/StatusBadge.test.tsx ui/src/lib/agent-order.test.ts ui/src/lib/onboarding-launch.test.ts ui/src/lib/work-mode-meta.test.ts ui/src/pages/IssueDetail.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` - `npx playwright test --config tests/e2e/playwright.config.ts --list tests/e2e/conference-room-typing-intro.spec.ts tests/e2e/planning-mode-visual-verification.spec.ts` - Attempted targeted Playwright execution locally, but this host is missing Chromium system libraries (`libatk1.0-0t64`, `libatspi2.0-0t64`, `libxcomposite1`, `libxdamage1`, `libxfixes3`, `libxrandr2`, `libgbm1`, `libasound2t64`). CI runs the specs in the proper Actions environment. ## Risks - Medium UI behavior risk: this intentionally changes the default experience for users who have not enabled Conference Room Chat. - Medium onboarding risk: completion now creates/reuses a project and creates the first task instead of only navigating. - Low migration risk: no database schema or migration changes are included. - The PR avoids `pnpm-lock.yaml` and `.github/workflows` changes. ## Model Used OpenAI Codex, GPT-5-class coding model, tool-enabled local repository workflow with shell, git, and test execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.5 |
||
|
DottaandPaperclip
|
b4a7efa8d2 |
Add skill category editing in settings (#8615)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Skills can be installed, inspected, filtered, and grouped inside company settings > - Skill category metadata already exists in the data model and list filters, but users could not edit categories after a skill was created or imported > - That made category filters and counts drift from the way operators actually want to organize their skills > - This pull request adds category editing to the existing skill settings dialog and sends those edits through the existing company-scoped skill update API > - The server mutation now includes category information in the activity log so settings changes are auditable > - The benefit is that operators can keep installed skills organized without reinstalling or recreating them ## Linked Issues or Issue Description No duplicate or closely related public GitHub issues or PRs were found for `skill categories settings`. Feature request fields: **Subsystem affected** Cross-cutting: `server/` REST API routes/services and `ui/` React board settings. **Problem or motivation** Company operators can create or import skills with categories, and Paperclip already exposes category filters and category counts. After installation, though, operators could not edit a skill's categories from the skill detail settings screen. That made it difficult to keep skills grouped correctly as workflows evolved. **Proposed solution** Add category editing to the existing skill settings dialog. The category field accepts comma-separated values, normalizes them into slugs, deduplicates repeated categories, allows clearing all categories, and saves categories together with the existing sharing setting through the company-scoped skill update API. **Alternatives considered** One alternative was to keep categories editable only during create/import flows, but that forces users to recreate or reinstall skills just to adjust grouping metadata. Another was a separate categories-only action, but batching settings into one explicit Save action keeps the dialog predictable. **Roadmap alignment** This supports the completed Skills Manager roadmap area by making installed skills easier to organize and maintain inside company settings. **Additional context** The server already persisted skill categories and supported category list filters/counts. This PR wires the existing metadata into the settings editing path and adds focused route, service, and UI tests. ## What Changed - Added category editing to the skill detail settings dialog, including comma-separated input, normalized deduplication, reset, dirty-state handling, and save feedback. - Updated the skill settings mutation path to save categories and sharing scope together, then refresh detail/list cache entries. - Included updated categories in `company.skill_updated` activity details. - Added server route/service coverage for category updates, normalization, filtering, counts, clearing, and activity logging. - Added UI coverage for saving category edits, clearing categories, reordered no-op category sets, saving sharing changes together, and preserving draft input after a failed save. - Updated the Storybook skill detail harness for the renamed settings callback props. ## Verification - `pnpm run preflight:workspace-links && pnpm exec vitest run server/src/__tests__/company-skills-routes.test.ts server/src/__tests__/company-skills-service.test.ts ui/src/pages/CompanySkills.test.tsx` - Latest-head GitHub checks are green for typecheck, build, e2e, general tests, serialized server suites, policy, commitperclip review, Socket Security, Snyk status, and Canary Dry Run. - Greptile Review succeeded on the latest head with zero unresolved review threads. ## Risks Low risk. The change uses the existing company skill update API and category normalization path. The main behavioral change is that the settings dialog now batches sharing and category edits behind an explicit Save button instead of saving sharing immediately on select 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 coding agent based on GPT-5, with tool-enabled repository inspection, shell execution, git, and GitHub CLI access. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.4 |
||
|
DottaandPaperclip
|
ed65d08d57 |
[codex] Gate skill mutations with skills:create permission (#8616)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents and board users operate inside a company-scoped control plane where permissions decide which mutating actions they can perform > - Company skills are part of the reusable agent-company setup surface, but skill mutation had been coupled to broader agent-creation authority > - That coupling meant importing or managing skills required a permission that also implies hiring power, which is broader than the operation needs > - Paperclip already has a grant-based permission vocabulary, so skill mutation should be authorized through a dedicated `skills:create` capability while preserving existing default behavior for trusted agents > - This pull request adds the skill creation permission contract, enforces it on company skill mutations, exposes it in agent permission management, and documents the changed CLI/API expectations > - The benefit is a narrower, auditable permission path for skill import/create/update/delete flows without forcing agents to receive broader agent-creation authority ## Linked Issues or Issue Description No public issue is linked. Problem: company skill mutation APIs were effectively tied to broader agent creation authority. This PR splits skill mutation authorization onto the public `skills:create` permission while keeping existing default skill creation behavior for agents unless explicitly disabled. Related public PR found during duplicate search: #5330. That PR uses an older `canManageSkills` shape; this PR implements the `skills:create` grant path instead. ## What Changed - Added `skills:create` to shared permission constants and agent permission types/validators as `canCreateSkills`. - Backfilled default human/member role grants for `skills:create`. - Updated company skill mutation routes to require board/user or agent access to `skills:create`, while preserving legacy/default agent behavior through `canCreateSkills` unless explicitly disabled. - Updated agent permission update handling, UI permission controls, duplicate-agent payloads, plugin SDK fixtures, and agent detail API surfaces for `canCreateSkills`. - Added regression coverage for skill route authorization, permission schema/default behavior, invite grants, omitted permission updates, and duplicate-agent payloads. - Updated CLI and Paperclip skill documentation for the new skill creation permission. ## Verification - `pnpm exec vitest run server/src/__tests__/agent-permissions-service.test.ts server/src/__tests__/agent-permissions-routes.test.ts server/src/__tests__/company-skills-routes.test.ts server/src/__tests__/invite-join-grants.test.ts ui/src/lib/duplicate-agent-payload.test.ts` — 5 files, 90 tests passed. - `pnpm --filter @paperclipai/shared typecheck && pnpm --filter @paperclipai/server typecheck && pnpm --filter @paperclipai/ui typecheck` — passed. - `pnpm test:run ...changed files...` was attempted first, but the stable wrapper rejects explicit file arguments; direct Vitest was used for the same targeted files. ## Risks - Moderate authorization risk: this changes the gate for company skill mutations, so the tests cover board grant checks, agent explicit grant checks, legacy default allowance, and explicit denial. - Migration/backfill risk is low: the migration only grants `skills:create` to existing human roles that already need broad management capability. - UI/API compatibility risk is low: `canCreateSkills` remains default-on for full agent permissions, and the update validator preserves omitted values so unrelated permission edits do not re-enable disabled skill creation. > 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 terminal/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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.3 |
||
|
Devin Foley
|
1951c80237 |
feat(cli): surface plugin install target host + add plugin target (#8575)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The CLI (`paperclipai plugin ...`) installs and manages plugins against a Paperclip server resolved from `--api-base` / `PAPERCLIP_API_URL` / the active profile / an inferred default > - During local plugin development you can have more than one Paperclip running (a released host plus a branch build on another port), and nothing told you *which* instance a command actually talked to > - So a plugin that depends on a route or response field only present on a feature branch could be silently installed/tested against a stale host, returning `API route not found`, and look broken when the real problem was the test target > - This pull request makes the install target explicit: it probes `GET /api/health` and prints the resolved API URL + server status/version/mode/exposure before installing, and adds a `plugin target` command plus docs for running and verifying against a branch service > - The benefit is that local plugin authors can confirm they are exercising the runtime they intend to, instead of debugging phantom plugin bugs caused by hitting the wrong server ## Linked Issues or Issue Description No public GitHub issue exists, so the underlying problem is described inline following the feature-request template. **Problem or motivation** Local plugin development assumes a single Paperclip on `http://127.0.0.1:3100`. When a plugin depends on server code that only exists on a feature branch (a new scoped route, a new response field, a new managed-resource capability), installing it into a long-lived host still on older code makes the route/field missing there. The plugin falls back or errors and *looks* broken, when the real cause is that it was tested against the wrong runtime. The CLI already let you point at any server, but it never surfaced which server you ended up on — so the mistake was invisible. **Proposed solution** Make the install target explicit. Before `plugin install` runs, probe `GET /api/health` and print the resolved API URL plus server status/version/deploymentMode/exposure, so the developer can confirm which Paperclip they are installing into. Add a standalone `plugin target` command to inspect the target without installing, a `--no-verify-target` escape hatch, and docs covering how to run a branch service on its own port and verify a branch route end-to-end. **Alternatives considered** - Do nothing and rely on the existing `--api-base` / `PAPERCLIP_API_URL` resolution — rejected because the gap was never the inability to point at a branch server, it was the lack of feedback about which server was actually hit. - Fail the install when the target looks stale — rejected as too aggressive; the probe is advisory and degrades gracefully when health details are not exposed or the server is unreachable. ## Dedup Search - [x] I searched the open and recently closed GitHub PRs for similar or duplicate PRs — this is not a duplicate ## What Changed - Add `probeTargetDiagnostics` / `formatTargetDiagnostics` helpers (`cli/src/commands/client/plugin.ts`) that read `GET /api/health` and report the resolved API URL plus server `status` / `version` / `deploymentMode` / `deploymentExposure`. - `plugin install` now prints these target diagnostics before installing, so you can confirm which instance you are installing into. Skippable with `--no-verify-target`. - `plugin install --json` keeps its original flat `PluginRecord` shape (top-level `id` / `pluginKey` / `version` / `status` are unchanged); when the target was probed it gains an additional top-level `target` field. Existing automation that reads the plugin fields keeps working. - Add a standalone `paperclipai plugin target` command to inspect the install target without installing anything. - Update `doc/plugins/LOCAL_PLUGIN_DEVELOPMENT.md`: how the CLI resolves its target, how to run a branch service on its own port and point the CLI at it explicitly, an end-to-end check that the branch route is actually served, and a troubleshooting entry for the stale-target symptom. - Unit tests for the diagnostics helpers (reachable + unreachable probe, and both render paths). ## Verification - `npx vitest run cli/src/__tests__/plugin-init.test.ts` — 10/10 pass (covers `probeTargetDiagnostics` success/failure and `formatTargetDiagnostics` rendering). - CLI typecheck (`tsc --noEmit` in `cli/`) — clean. - Manual: with a server running, `paperclipai plugin target` prints `Target Paperclip: <url>` and the health line; `plugin install` prints the same block before installing and `--no-verify-target` skips it. ## Risks Low risk. The probe is read-only (`GET /api/health`) and runs before install; if the server does not expose details it degrades to `ok (no details exposed)`, and an unreachable target prints a remediation hint rather than failing the command. The `--json` output keeps its original flat shape, so existing scripts are unaffected. No server or schema changes. ## Model Used Claude Opus 4.7 (`claude-opus-4-7`), extended thinking + tool use, via Claude Code.canary/v2026.625.0-canary.2 |
||
|
Devin FoleyandPaperclip
|
721541c41d |
Fix sandbox restore index drift (#8595)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Sandboxed agents can do useful work in a remote workspace, then export that result back to a host review checkout. > - A restore can leave the host checkout's index stale even when the sandbox content and committed state are correct. > - That drift makes reviewers see misleading missing-file or dirty-state results after sandbox execution. > - This pull request repairs the host index refresh path and surfaces a clean/dirty restore signal during finalization. > - The benefit is more reliable review checkouts and clearer sandbox finalization status. ## Linked Issues or Issue Description Refs #248 No exact public GitHub issue was found for this restore/index consistency fix. The underlying bug is that a sandbox restore can update host working-tree content without leaving the host git index aligned, so local review tooling may report stale deletions or misleading dirtiness. This PR keeps the restore/export path consistent and reports the resulting clean/dirty state. GitHub search performed for related or duplicate work: `sandbox runtime status`, `sandbox restore index`, and `runtime progress`. No direct duplicate PR was found. ## What Changed - Refreshed git workspace sync/index handling after sandbox restore/export operations. - Added finalization status that reports whether the restored host checkout is clean or dirty. - Preserved sandbox-managed runtime progress callbacks around restore and finalization. - Added adapter-utils tests covering the host index drift repair and clean/dirty finalization signal. ## Verification - Local PII scan before push: high-confidence secret patterns, internal issue links, local user paths, and private URL patterns checked across all three split diffs; no real secrets or internal links found. - `git diff --check feat/sandbox-runtime-status..fix/sandbox-restore-index-sync` - `pnpm exec vitest run packages/adapter-utils/src/sandbox-managed-runtime.test.ts` — 1 file, 10 tests passed. - `pnpm run typecheck` passed on `fix/sandbox-restore-index-sync`. - `pnpm run build` passed on `fix/sandbox-restore-index-sync`; Vite reported existing CSS `::highlight` and chunk-size warnings. - `pnpm run test:run` was attempted on `fix/sandbox-restore-index-sync`; it failed in two unrelated broad-suite tests. One depends on this host's Git default branch behavior, and one depends on local Claude model-discovery environment. The changed focused suite above passes. ## Risks - Git index refresh behavior needs to remain conservative so it does not hide real uncommitted user changes. - The clean/dirty finalization signal is diagnostic; it should not by itself mark a sandbox run successful or failed. - This PR is stacked on the runtime-status branch so finalization progress can reuse the same callback path. > 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 via Codex coding agent, with shell/tool execution in a local worktree. Exact context-window metadata is 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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.625.0-canary.1 |
||
|
|
800dab1c64 |
Render sandbox runtime status in issue threads (#8594)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The issue thread is where operators watch active agent work and decide whether a run is healthy. > - Backend runtime-progress plumbing can expose a concise current status, but users only benefit if the issue UI renders it in context. > - The UI should show that current status as part of the active run surface without turning it into durable transcript content. > - This pull request adds the issue-thread rendering and message formatting needed for sandbox runtime status. > - The benefit is that active sandbox setup phases are visible from the normal issue detail view. ## Linked Issues or Issue Description Refs #248 No exact public GitHub issue was found for this UI rendering work. The underlying problem is that active sandboxed runs can have backend progress state without any concise issue-thread display, leaving users to infer whether setup is still moving. This PR adds the UI layer on top of the runtime-status API branch. GitHub search performed for related or duplicate work: `sandbox runtime status`, `sandbox restore index`, and `runtime progress`. No direct duplicate PR was found. ## What Changed - Included current runtime status in the heartbeat API client shape. - Rendered active run status text in the issue chat thread when available. - Updated issue-chat message formatting helpers for runtime status display. - Added focused component and formatting tests for the new active-run status behavior. ## Verification - Local PII scan before push: high-confidence secret patterns, internal issue links, local user paths, and private URL patterns checked across all three split diffs; no real secrets or internal links found. - `git diff --check feat/sandbox-runtime-status..feat/sandbox-status-ui` - `pnpm exec vitest run ui/src/components/IssueChatThread.test.tsx ui/src/lib/issue-chat-messages.test.ts` — 2 files, 91 tests passed. - `pnpm run typecheck` passed on `feat/sandbox-status-ui`. - `pnpm run build` passed on `feat/sandbox-status-ui`; Vite reported existing CSS `::highlight` and chunk-size warnings. - Visual evidence (desktop + mobile) is attached to the tracking issue rather than committed to the repo. ## Risks - This PR is stacked on the runtime-status API branch and depends on that response/event shape. - The status line is intentionally concise; long or sensitive status content should continue to be bounded/redacted by the backend. - The visual change is limited to active issue-thread runs with current runtime status data. > 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 via Codex coding agent, with shell/tool execution in a local worktree. Exact context-window metadata is 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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip CTO <cto@paperclip.local> Co-authored-by: Paperclip CTO <noreply@paperclip.ing> |
||
|
|
a27e5ad002 |
Add ephemeral sandbox runtime status plumbing (#8593)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Sandboxed agent runs can spend meaningful time preparing a remote workspace before the agent transcript shows useful output. > - Operators need short, current progress text for those setup phases, but that text should not become durable run history. > - The existing live-run websocket path already carries run updates to the UI, so the backend can reuse that channel instead of adding polling. > - This pull request adds an ephemeral runtime-progress contract, a process-local status store, and heartbeat integration for sandbox-managed runs. > - The benefit is a clearer active-run experience without database migrations or persistent progress rows. ## Linked Issues or Issue Description Refs #248 No exact public GitHub issue was found for this status-message plumbing. The underlying problem is that active sandboxed runs currently have setup phases, such as workspace sync and restore, where the operator cannot see concise current progress through the live run state. This PR addresses that gap for the backend/runtime layer while keeping progress messages ephemeral. GitHub search performed for related or duplicate work: `sandbox runtime status`, `sandbox restore index`, and `runtime progress`. No direct duplicate PR was found. ## What Changed - Added shared runtime-progress types and the `heartbeat.run.progress` live event type. - Added a process-local heartbeat run runtime-status store with TTL, bounded/redacted messages, and terminal cleanup. - Threaded runtime progress callbacks through heartbeat execution and active/live run serialization. - Emitted sandbox-managed runtime phase updates for sync, adapter startup, restore/export, and finalization paths. - Added backend and adapter-utils tests for ephemeral status behavior, terminal cleanup, live serialization, and sandbox progress callbacks. ## Verification - `pnpm install --frozen-lockfile` - Local PII scan before push: high-confidence secret patterns, internal issue links, local user paths, and private URL patterns checked across all three split diffs; no real secrets or internal links found. The only secret-like text is an intentional fake test fixture (`sk-test-secret`). - `git diff --check origin/master..feat/sandbox-runtime-status` - `pnpm exec vitest run server/src/services/heartbeat-run-runtime-status.test.ts server/src/__tests__/heartbeat-runtime-state.test.ts server/src/__tests__/agent-live-run-routes.test.ts packages/adapter-utils/src/sandbox-managed-runtime.test.ts` — 4 files, 23 tests passed. - `pnpm run typecheck` passed on both top stacks that include this branch: `feat/sandbox-status-ui` and `fix/sandbox-restore-index-sync`. - `pnpm run build` passed on both top stacks that include this branch; Vite reported existing CSS `::highlight` and chunk-size warnings. - `pnpm run test:run` was attempted on `fix/sandbox-restore-index-sync`; it failed in two unrelated broad-suite tests. One depends on this host's Git default branch behavior, and one depends on local Claude model-discovery environment. The changed focused suites above pass. ## Risks - Runtime progress is process-local by design, so status disappears after TTL, terminal cleanup, or server restart. - Clients that do not consume `heartbeat.run.progress` simply keep existing behavior. - Message redaction is intentionally generic; overly specific phase details should stay out of runtime-progress payloads. > 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 via Codex coding agent, with shell/tool execution in a local worktree. Exact context-window metadata is 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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip CTO <cto@paperclip.local> Co-authored-by: Paperclip CTO <noreply@paperclip.ing>canary/v2026.625.0-canary.0 |
||
|
|
bac15ebd09 |
feat: task status icons & colors (#8580)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work, and task status is one of the most-scanned signals across its whole UI. > - The Tasks UI shows status through small coloured ring icons and chips spread across the list, kanban, task detail, the properties flyout, inline `@`-mentions and the breadcrumb. > - Those ring glyphs lean heavily on colour to distinguish states, which is hard to read for colour-blind users, and the status hues were hard-coded in component classes rather than a single source. > - We want color-blind-safe, distinct *shapes* per status plus a single `--status-*` colour-token system the chips and icons share. > - This pull request adds a unified `StatusGlyph` (one shape per status) and the `--status-*` colour-token system, and adopts them across every task-status surface so the new glyphs + colours render by default. > - The benefit is a more accessible, consistent status language with one source of truth for status hues. ## Linked Issues or Issue Description This is a **feature** (no public issue filed). Following the feature issue template: - **Problem / motivation:** Task status is communicated mostly by colour (ring fills/borders), which is hard to distinguish for colour-blind users, and the status hues are duplicated across component classes with no single source of truth. Several community PRs have nibbled at parts of this (see related PRs below). - **Proposed solution:** A single `StatusGlyph` component with a distinct *shape* per status (not just colour), backed by a `--status-*` CSS-variable colour system (base hues + AA-tuned icon hues + `.status-chip` / `.status-fill` color-mix helpers), adopted across all task-status surfaces. - **Alternatives considered:** Recolouring the existing rings in place (rejected — still colour-only, no shape differentiation). - **Roadmap alignment:** Additive UI only; no overlap with planned core work. Related community PRs (partial / different approaches to the same area — not duplicates): - Refs #3806 — Show issue ref and status icon in breadcrumbs and properties - Refs #1760 — Improve design of cancelled task status icon - Refs #1856 — a11y title/aria-label on status and priority icons ## What Changed - **Colour token system:** `--status-agent-*` / `--status-task-*` base hues, AA-tuned `--status-task-icon-*` hues (light + dark), and `.status-chip` / `.status-fill` color-mix helpers in `index.css`; matching status→CSS-var maps in `status-colors.ts`. - **`StatusGlyph`** — one `viewBox="0 0 24 24"` glyph per status with distinct, color-blind-safe shapes (dashed ring, open ring, half-fill, ring+dot, disc+check, ring+bar, ring+slash, and `in_queue` = the blocked shape recoloured blue). Sizes `sm`/`md`/`lg`. - **Adoption (renders by default)** across `StatusIcon`, `StatusBadge` (agent + issue chips), `MarkdownBody` inline mentions, `IssueRow`, `IssuesList`, `IssueProperties`, `BreadcrumbBar` + `BreadcrumbContext`, and the task-detail header/breadcrumb. - **Tests** for `StatusGlyph`, `StatusIcon`, `StatusBadge`, `IssueRow`, `IssuesList`, `MarkdownBody` lock the rendered behaviour. Scope notes: no experimental flag and no Theme Editor surfaces. The generic `StatusBadge` (runs/goals/approvals) is unchanged. Project-status recolour is deferred (no in-scope consumer). ## Verification - `pnpm --filter @paperclipai/shared build` — green (tsc). - `pnpm --filter @paperclipai/ui build` — green (tsc + vite). - Targeted unit tests green: `StatusGlyph`, `StatusIcon`, `StatusBadge`, `IssueRow`, `IssuesList`, `MarkdownBody`, plus consumer suites that render these (`IssueProperties`, `IssueDetail`, `Search`, `IssueChatThread`, `IssueFiltersPopover`, `InterruptHandoffViews`) — all passing. - Remaining: interactive light + dark visual confirmation across list / kanban / detail / properties / inline mentions / breadcrumb. The glyph shapes + AA-tuned hues were previously QA'd on the originating feature branch. ## Risks Low risk. Additive UI: a new component + CSS tokens, adopted at existing status call sites. The generic `StatusBadge` and all non-status UI are untouched; no schema/migration changes. Behaviour is exercised by unit + consumer test suites. ## Model Used Claude Opus 4.8 (`claude-opus-4-8`), extended thinking, with tool use / code execution (file edits, local builds + vitest). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.624.0-canary.4 |
||
|
DottaandPaperclip
|
50ae8fc657 |
[codex] Improve reusable workspace selector search (#8597)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The new issue dialog lets operators create follow-up tasks and optionally reuse an existing execution workspace > - Reusing a workspace depends on a searchable selector that can include workspace names, branches, and local paths > - The selector previously treated all matched text equally, so hidden path text could outrank the visible workspace label and unrelated fuzzy letter matches could leak into results > - The reusable workspace popover also needed to stay inside the modal so scrolling and layering behave like the rest of the dialog > - This pull request improves the shared searchable select scoring and applies it to reusable execution workspace choices > - The benefit is a more predictable workspace reuse flow when an operator searches by branch, task name, or workspace label ## Linked Issues or Issue Description No public GitHub issue found for this selector bug. ### Pre-submission checklist - [x] I have searched existing open and closed issues and this is not a duplicate. - [x] I am on the latest released version of Paperclip (or can reproduce on `master`). - [x] I have confirmed the error originates in Paperclip itself — not in my agent adapter, API provider, or local configuration. ### What happened? Workspace searches could rank hidden path matches ahead of direct visible label matches, and broad fuzzy matching could match letters spread across unrelated workspace metadata. ### Expected behavior Direct label/name matches should sort ahead of weaker hidden metadata matches, and fuzzy matching should stay constrained enough to avoid unrelated workspace results. ### Steps to reproduce 1. Open the new issue dialog. 2. Choose reuse existing execution workspace. 3. Search for a term that appears in one workspace label and only in another workspace path. 4. Observe that the path-only match can rank ahead of the direct visible label match. ### Paperclip version or commit Current `master` before this change. ### Deployment mode Local dev (`pnpm dev`). ### Installation method Built from source (`pnpm dev` / `pnpm build`). ### Agent adapter(s) involved - [x] Not adapter-specific (core bug) ### Database mode Not database-related. ### Access context Board (human operator). ### Node.js version Not version-specific. ### Operating system Not OS-specific. ### Relevant logs or output No logs; this is client-side selector behavior. ### Relevant config (if applicable) None. ### Additional context This PR also keeps the reusable workspace selector popover inside the modal and contains command-list scroll events to keep the dialog interaction stable. ### Privacy checklist - [x] I have reviewed all pasted output for PII (usernames, file paths, API keys, tokens, company names) and redacted where necessary. ## What Changed - Added fuzzy scoring helpers for searchable text fields, including field weights for visible labels versus secondary search metadata. - Updated `SearchableSelect` to sort filtered results by score while preserving original order for ties and custom filters. - Updated reusable execution workspace matching to prefer visible labels, then descriptions, then hidden search text. - Kept the reusable workspace selector popover inside the new issue modal and contained wheel/touch scrolling in the command list. - Added unit/component coverage for selector ranking, reusable workspace matching, modal popover containment, and scroll containment classes. ## Verification - `pnpm exec vitest run ui/src/lib/searchable-select.ts ui/src/lib/reusable-execution-workspaces.test.ts ui/src/components/SearchableSelect.test.tsx ui/src/components/NewIssueDialog.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` ## Risks Low risk. The change is scoped to client-side searchable selector ranking and modal popover behavior. The main behavior shift is that searches are intentionally less permissive for unrelated fuzzy letter spreads, which should reduce noisy results but could hide a result someone previously reached through very loose matching. ## Model Used OpenAI Codex, GPT-5-based coding agent with repository file access, shell/tool execution, and medium reasoning effort. Exact hosted model build and context window were not surfaced 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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.624.0-canary.3 |
||
|
Devin FoleyandPaperclip
|
51ffbb380f |
Exclude transient Codex home dirs from sandbox sync (#8581)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Local adapters can run agents against sandboxed execution targets by syncing the workspace and selected runtime assets into the sandbox. > - The Codex local adapter includes a managed Codex home asset so sandboxed Codex runs can use the expected auth, config, skills, and session state. > - That asset follows symlinks, which is useful for real Codex home content but unsafe for transient launcher directories. > - Transient `tmp` and `.tmp` directories can contain symlinks to large host binaries, so the sandbox archive can inline large executable targets instead of just the small home directory content. > - This pull request excludes transient Codex home directories from the sandbox home asset while preserving the required Codex home files. > - The benefit is a much smaller and more predictable sandbox setup upload without changing the runtime files Codex actually needs. ## Linked Issues or Issue Description No public issue was found for this exact sandbox archive-size bug. Bug description: - What happened: sandboxed `codex_local` runs sync the managed Codex home as a `home` asset with `followSymlinks` enabled. If transient Codex home dirs such as `tmp` or `.tmp` contain symlinks to a large host binary, the archive can inline that binary and make `Syncing home to sandbox` much larger than the managed home directory itself. - Expected behavior: sandbox setup should include the Codex home files needed for auth, config, skills, and session continuity, but should not archive transient launcher scratch directories. - Reproduction shape: create a managed Codex home with normal auth/config/skills files and a `tmp/arg0` or `.tmp` symlink to a large host executable, then start a sandboxed `codex_local` run. The home asset archive grows by the symlink target size. - Version/commit: observed on local `master` before this change. - Related public context: #5028 covers a different managed Codex home reliability issue around stale auth files; this PR addresses sandbox archive bloat from transient symlink targets. ## What Changed - Excluded `tmp` and `.tmp` from the Codex `home` asset that is uploaded for sandboxed runs. - Added regression coverage proving transient symlinked home dirs are excluded from the tar while required auth/config/skills files remain included. - Kept `followSymlinks` behavior for the rest of the Codex home asset so existing non-transient symlink behavior is preserved. ## Verification - `git diff --check` - Local PII/secret pattern scan over the committed diff - `pnpm exec vitest run packages/adapter-utils/src/sandbox-managed-runtime.test.ts` - `pnpm --filter @paperclipai/adapter-utils typecheck` - `pnpm --filter @paperclipai/adapter-codex-local typecheck` ## Risks Low risk. The exclusion is limited to transient Codex home scratch directories, and the regression test verifies the files needed in the sandbox are still archived. The main compatibility risk is if a user intentionally placed required persistent Codex state under `tmp` or `.tmp`; those paths are treated as volatile scratch space by this change. ## Model Used OpenAI Codex coding agent based on GPT-5, with shell, git, and GitHub CLI tool use. Exact hosted model build and context-window size were not exposed in 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 searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.624.0-canary.2 |