PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-11-06 14:02:36 +01:00

Author	SHA1	Message	Date
DottaandPaperclip	8c3b8c432a	Simplify app connections and enable managed Google access (#12728 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The Apps subsystem gives humans and agents governed access to external tools. > - The current connection flow hides Apps behind an experimental gate and repeats setup text. > - Google sharing choices and generic MCP permissions do not use one consistent opening model. > - Self-hosted installs also need a safe default origin for managed OAuth without a manual config file. > - This pull request makes Apps available, simplifies connection setup, and applies one governed permissions model. > - The benefit is a shorter connection flow that works on a clean self-hosted install. ## Linked Issues or Issue Description What existing behavior does this improve? This improves the Apps connection setup flow, managed Google connection flow, generic MCP connection flow, navigation, and runtime origin discovery. Subsystem affected Cross-cutting. This changes `ui/`, `server/`, `packages/shared/`, connector documentation, and browser tests. Current behavior Apps require an experimental switch. Setup pages repeat titles and explanatory copy. Connection names require manual input. Google credential sharing does not always offer both personal and organization access. Generic MCP providers do not start with the same permission choices. Managed OAuth needs a public URL setting even when the request already has a safe HTTPS origin. Proposed behavior Apps are available by default. Setup asks only for required permissions and sharing choices. Paperclip creates conflict-free connection names. Google apps and generic MCP providers use the same human and agent access model. Managed OAuth derives a validated same-origin HTTPS URL when no explicit public URL is set. Reason and benefit A clean self-hosted install can connect a managed Google app without hidden setup. Humans can share a service account with their organization. The shorter flow reduces duplicated choices and setup errors. Breaking changes The Apps experimental switch is removed. Existing connection APIs remain compatible. New connections can receive a numeric suffix when a name already exists. No duplicate or related public issue was found. ## What Changed - Removed the Apps experimental gate and the breadcrumb that leaves the Apps section. - Simplified all connection setup pages and moved optional provider requirements into one small link. - Added consistent human and agent access choices for Google apps, Zapier, and generic MCP connections. - Added organization sharing to Google Workspace credentials while keeping personal access available. - Generated connection names automatically and resolved name conflicts with numeric suffixes. - Derived a validated public HTTPS origin from the request for config-free managed OAuth. - Updated connector contracts, tests, browser coverage, and authoring documentation. ## Verification - `pnpm check:token-gates` - `pnpm -r typecheck` - `pnpm build` - `pnpm exec vitest run server/src/__tests__/tool-access-service.test.ts server/src/__tests__/generic-mcp-connection.test.ts` (273 passed) - Targeted UI/service regression suite (308 passed) - Six targeted Playwright connection journeys on a fresh onboarding instance (6 passed) - Fresh-install browser proof through Tailscale HTTPS: enrolled with Paperclip Cloud, connected managed Google Drive, and completed a real read operation. - [Exact-head CI run](https://github.com/paperclipai/paperclip/actions/runs/33669760711): all 23 matrix jobs passed, including build, typecheck, server, serialized, canary, and all browser shards. - Greptile 5/5 on `0ae2a859f269984ee950d0af231a5b09a06f3dfd`, with no unresolved review threads. ## Risks Apps are now visible to all operators. The removed experimental flag no longer hides unfinished app definitions. Managed Google availability still depends on the Cloud profile rollout and active instance enrollment. Automatic conflict handling changes only the display name of a newly conflicting connection. > I checked [`ROADMAP.md`](ROADMAP.md). MCP Tool Gateway and Apps are shipped. Connected Apps is planned, and this change improves the existing shipped connection flow. ## Model Used OpenAI Codex, GPT-5, with reasoning, browser control, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-09-02 14:05:53 -05:00
DottaandPaperclip	4b6de5327e	Remove cheap model profiles (#12683 ) ## Thinking Path > - Paperclip manages agents that use different model providers and adapters. > - Paperclip must keep agent execution rules clear and predictable. > - The cheap-model profile added a second execution mode across adapters, task recovery, APIs, and the UI. > - That mode increased configuration and recovery complexity. > - This pull request removes the cheap-model profile as a product feature. > - The benefit is one model-selection path for normal work and recovery work. ## Linked Issues or Issue Description What existing behavior does this improve? This change simplifies model selection across agent configuration, task execution, recovery, and adapter capabilities. Current behavior Paperclip exposes cheap-model profiles in adapter metadata, agent runtime configuration, task overrides, recovery rules, APIs, and the board UI. Recovery work can select a different model profile from the agent's configured model. Proposed behavior Paperclip uses the agent's configured model for normal work and recovery work. Status-only recovery stays limited to coordination work. The API rejects legacy model-profile configuration. A migration removes stored model-profile values from existing agent, issue, and historical revision records. Reason and benefit One model path reduces configuration, API, UI, and recovery complexity. It also prevents status recovery from becoming a separate product-level model-routing feature. Breaking changes This change removes model-profile fields and adapter capability metadata. Existing stored model-profile values are removed by an idempotent migration. The validators reject new legacy profile values with clear errors. ## What Changed - Removed model-profile types, adapter capabilities, API fields, and model selection logic. - Removed cheap-model controls from agent and task UI surfaces. - Kept status-only recovery limited to coordination context while normal continuations use the configured agent model. - Added an idempotent migration that removes stored model-profile values from agents, issues, and configuration revisions without changing issue update timestamps. - Updated tests and product documentation for the single-model behavior. ## Verification - `pnpm check:token-gates` passes. - `pnpm -r typecheck` passes. - `pnpm build` passes. - `pnpm test:run` completed with 5,607 passing tests and 8 environment-sensitive failures in unrelated fixed-port and database-deadlock suites. The same failures repeated in an isolated rerun. CI is the final clean-room result. ## Risks - This is an intentional breaking change for clients that send model-profile fields. - The migration changes legacy agent, issue, and configuration-revision JSON. It is idempotent and preserves unrelated fields and issue update timestamps. - The change is cross-cutting because the removed feature existed in adapters, shared contracts, the server, plugins, and the UI. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex with `gpt-5`. Reasoning and tool use were enabled. The runtime did not expose the context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [ ] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-09-01 14:57:38 -05:00
Dotta	1ab159d3a7	feat(apps): consolidate connector management (#12684 ) Completes the post-managed-OAuth connector lifecycle, Paperclip Cloud provisioning defaults, governed test flows, and consolidated Apps UI.\n\nCo-Authored-By: Paperclip <noreply@paperclip.ing>	2026-09-01 14:55:35 -05:00
DottaandPaperclip	141f202e40	Clean up experimental settings features (#12681 ) ## Thinking Path > - Paperclip is the open source app that people use to manage AI agents for work. > - Instance settings control optional product features and developer tools. > - The experimental settings page mixed active experiments, internal tools, and old recovery controls. > - Some workspace links also used the selected company instead of the workspace owner. > - These problems made settings hard to scan and could send users to the wrong company route. > - This pull request removes old controls, groups developer settings, and resolves workspace links from workspace data. > - The benefit is a smaller settings surface and correct workspace navigation. ## Linked Issues or Issue Description What existing behavior does this improve? This improves the instance experimental settings page, task watchdog controls, dependency wake recovery, and execution workspace routes. Current behavior The settings page shows old recovery controls and mixes product experiments with internal developer settings. Task watchdogs require an extra feature flag. Some direct workspace links use the current company prefix instead of the company that owns the workspace. Proposed behavior Remove the old task recovery experiment and its unused API surface. Make task watchdog controls available without the removed flag. Put worktree execution and managed environment controls in the developer section. Resolve direct workspace links from the workspace owner and reject a company prefix that does not own the workspace. Reason and benefit The smaller settings page is easier to understand. The server keeps only the dependency wake backstop that it still uses. Workspace links open under the correct company route. Breaking changes This removes the experimental issue graph recovery preview and run endpoints. It also removes the task watchdog feature flag. Task watchdog data and dependency wake behavior remain available. ## What Changed - Removed the old task watchdog and issue graph recovery feature flags. - Removed the old issue graph recovery preview, run controls, API contracts, and unused recovery implementation. - Kept resolved dependency wakes as the scheduler backstop. - Grouped product experiments and Paperclip developer settings on the instance settings page. - Made task watchdog controls available without an extra experimental flag. - Added owner-aware redirects and company checks for execution workspace routes. - Hid the false stopped-state badge while a workspace has no active runtime state. - Updated focused server and UI tests for the new behavior. ## Verification - `pnpm check:token-gates` - `pnpm -r typecheck` - `pnpm build` - `pnpm test:run` completed with 5,620 passing tests and four failures in unchanged workspace runtime port tests. The same four failures repeat when the two files run alone. - The complete GitHub CI matrix passed, including all server, serialized server, build, canary, and end-to-end jobs. ## Risks - Clients that call the removed experimental recovery endpoints must stop calling them. - The route checks depend on workspace detail access. An unknown or cross-company workspace returns the global not-found page. - There are no database migrations, lockfile changes, workflow changes, or design image 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 with GPT-5. The exact deployment ID and context window are not exposed. Reasoning, tool use, and code execution were 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>	2026-09-01 14:23:05 -05:00
TonioandClaude Opus 5	42c6f8a424	Onboarding: model source tiles, one input canvas, and Storybook coverage for the agent arc (#12613 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - New customers meet it through onboarding, whose last three steps run inside the tenant: create an agent, connect a model, review > - The connect step is the one that decides whether the agent can run at all, and it had drifted — three contributors changed it in parallel, and its visual language no longer matched the rest of the flow > - It also could not be looked at without a provisioned stack, so defects in it were only found by walking a real signup, and the review step behind it could not be reached at all when it failed > - This pull request brings the visual work onto the sign-in behaviour that already shipped, and adds Storybook coverage for all three steps > - The benefit is that the step is easier to read, and that it can now be inspected and driven before it ships rather than after ## Linked Issues or Issue Description What existing behavior does this improve? The onboarding connect-a-model step. It presented the model choice as a dropdown plus an "Advanced settings" disclosure, and put each credential type in a different place, so the controls below moved whenever the choice changed. Subsystem affected Tenant onboarding wizard (`ui/src/components/OnboardingWizard.tsx`) and its Storybook coverage. Current behavior The step offered every registered adapter through a disclosure. Credential entry appeared in a different shape per source. None of the three agent-arc steps could be rendered outside a provisioned cloud stack, so the sign-in panel and the review step were only reachable by walking a real signup. Proposed behavior Two brand tiles for the recommended sources, a link that switches between subscription and API-key credentials, and one canvas that holds whichever input the current choice needs. Storybook stories mount the real wizard against fixtures and walk it forward, so every step and its states can be inspected locally. Reason and benefit The step reads as one decision rather than three scattered ones, and its furniture stays still while the choice changes. The stories mean a regression in it is visible before release instead of during a signup. Breaking changes No API or schema change. One behavioural narrowing, described under Risks. ## What Changed - Replaces the adapter dropdown and "Advanced settings" disclosure with `ModelSourceTiles` — brand tiles for Claude Code and Codex. - Adds `CredentialModeLink`, a text toggle between subscription sign-in and API keys, replacing the disclosure. - Adds `ConnectInputCanvas`: one surface that holds the sign-in panel or the API-key field and resizes between them, so the Connect button below does not move. - Keeps the existing sign-in behaviour unchanged. `AgentConfigForm` changes are presentation only — the provider name in the title, the CTA wording, and `space-y` to `gap`. No change to the login mutations, queries, or session handling. - Restores the sleep marks on the dormant agent for the two steps before the hire. - Adds Storybook stories for all three agent-arc steps, with fixtures for the environments, auth signal, both adapters' login flows, and the hire. - Copy: names the provider being signed in to ("Sign in to Anthropic"/"Sign in to OpenAI"), and drops "Clippy" from the agent-name helper text. ## Verification - `pnpm vitest run src/components storybook` in `ui/` — 139 tests over the touched suites, 1986 across `src/components`. - `pnpm typecheck` in `ui/` — clean. - Storybook, `Onboarding/Agent arc`: walk each story. Step 1 has no Back button, steps 2 and 3 do. - The sign-in gate: on `Connect a model`, press Connect without signing in. It holds on step 2 and reports "No working authentication was found." On `Review`, which fixtures an authenticated signal, Connect reaches the review step. - Both providers' login flows: press Sign in on the Claude tile for the authorization URL and browser-code field, and on the Codex tile for the device URL and code. - The Claude sign-in was also walked end to end on a staging tenant, including the OAuth redirect and pasting the code back. ## Risks - Onboarding now offers two model sources instead of every registered adapter. `ModelSourceTiles` is fed the `recommended` set, which is `claude_local` and `codex_local`; Gemini, Cursor, Grok, Kimi, OpenCode and Paperclip Runner are no longer selectable during onboarding. This is deliberate. The full list is unchanged in agent settings, which is where an adapter can still be switched after the agent exists, and adding a source back is one `recommended: true` in `adapter-display-registry.ts`. Flagging it because it is the one behavioural narrowing here and it is not visible from the diffstat. - The API key entered on this step is held in component state and deliberately never written to the onboarding draft, because that draft is `localStorage`. A customer who leaves mid-step re-enters the key; that is the intended trade. - Storybook-only risk: the fixtures now answer the environment test from the story's auth state. If a future change moves the hire's gate off the `adapter_auth_missing` check code, the stories would keep passing while the product regressed. The gate is asserted in the adapter packages' own tests, not here. - Motion changes are low risk and reversible: the input canvas animates its contents only, and its container was deliberately left unanimated after an animated wrapper clipped the sign-in panel. ## Model Used Claude Opus 5 (`claude-opus-5`), via Claude Code with extended thinking, tool use, and browser-driven verification of the Storybook stories. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 09:57:46 -07:00
Dotta	ee2a190626	Unify Paperclip Runner experimental controls (#12666 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip Runner is an experimental execution adapter. > - The adapter and its required sandbox ingress had separate settings. > - A user could enable one setting and still have an unusable runner configuration. > - The runtime already makes one durable native or legacy decision for each run. > - This pull request uses that runtime decision for ingress authorization. > - The benefit is one clear opt-in with safe recovery for existing native runs. ## Linked Issues or Issue Description What existing behavior does this improve? This improves the experimental settings and transport authorization for Paperclip Runner. Subsystem affected Cross-cutting. This change affects the React settings UI, shared settings contracts, adapter utilities, and server runtime selection. Current behavior Settings shows separate Paperclip Runner and Runner Preview Ingress controls. A user can enable the runner but leave required sandbox ingress disabled. Proposed behavior Settings shows only Paperclip Runner. Its native runtime decision also authorizes provider WebSocket ingress when the execution target requires it. A persisted native run keeps its recovery transport after the setting is disabled. Reason and benefit Paperclip Runner is one experimental capability. One opt-in removes an invalid partial configuration and makes the rollout boundary easier to understand. Breaking changes The Runner Preview Ingress card is removed. The old `enableRunnerPreviewIngress` key remains accepted in stored settings and managed configuration, but it has no server runtime effect. The public adapter-utils input remains compatible through a deprecated alias. Additional context Refs: #12638, #12641, #12656. ## What Changed - Removed the separate Runner Preview Ingress card from Experimental Settings. - Made resolved native runtime selection authorize required provider ingress. - Preserved ingress recovery for persisted native runs after the rollout flag is disabled. - Kept the old settings key and adapter-utils input as deprecated compatibility contracts. - Added focused UI, runtime policy, transport, stored-settings, and managed-config regression tests. - Updated deployment documentation and feature descriptions. ## Verification - GitHub Actions will run typecheck, tests, build, policy, and browser shards. - Focused tests cover the single settings control, runtime authorization, fail-closed transport selection, the deprecated public input, and old managed configuration. - No local tests were run, per the maintainer request to use GitHub Actions for verification. - `git diff --check` passes. ## Risks Low to moderate risk. The effective ingress gate changes from a separate stored flag to the resolved native run decision. Fresh runs still require `enableNativeRunner`. Persisted native runs remain recoverable. Legacy adapters never receive ingress authorization. > 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, with reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [ ] 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	2026-09-01 09:21:23 -05:00
Dotta	1955b0e2d8	Gate Paperclip Runner setup behind an experimental flag (#12656 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent adapters control how Paperclip starts and resumes an agent runtime. > - Paperclip Runner is an experimental Rust runtime and must stay opt-in. > - The server already rejected new runner selections when the flag was off. > - Some setup and onboarding views did not enforce the same boundary. > - This pull request exposes the existing flag and applies it to every new setup path. > - The benefit is a safe rollout with unchanged legacy onboarding and recoverable existing native runs. ## Linked Issues or Issue Description What existing behavior does this improve? This improves experimental adapter selection in Settings, onboarding, new-agent setup, invite setup, and company import. Subsystem affected Cross-cutting: the React UI and the server onboarding seed service. Current behavior The server defaulted Paperclip Runner to off, but Settings did not expose the flag. First-run onboarding could show the runner after opt-in. A direct new-agent URL and some setup pickers could also reveal native runner configuration before the availability check completed. Proposed behavior Settings has a default-off Paperclip Runner toggle. Explicit agent configuration shows the runner only after the server reports that the flag is enabled. First-run and invite onboarding always use legacy adapters. Existing native agents and runs remain readable and recoverable. Reason and benefit This keeps the experimental runtime out of normal onboarding. It also gives administrators one clear opt-in before users can create a native runner agent. Breaking changes None. Legacy adapter selection and execution stay unchanged. Existing native records remain available. ## What Changed - Added the Paperclip Runner opt-in to Experimental Settings. - Refreshed adapter availability after the setting changes. - Kept UI and server-seeded onboarding on legacy adapters. - Made native runner choices fail closed in new-agent, invite, and import setup. - Preserved edit and recovery behavior for existing native agents and runs. - Added focused regression tests for flag-off and flag-on behavior. ## Verification - GitHub Actions will run the repository test, typecheck, build, and policy gates. - Focused tests cover Settings, onboarding, agent creation, invite setup, import setup, and server-seeded onboarding. - No local test suite was run, per the maintainer request to use GitHub Actions for verification. - `git diff --check` passes. ## Risks Low risk. The change narrows new adapter selection only. The server remains the final enforcement point. Existing native records do not depend on the current flag value for read or recovery behavior. > 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, with reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [ ] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-01 05:57:40 -05:00
Dotta	131f5c4065	feat(runner): add administration and observability (#12641 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Administrators need bounded controls for experimental native execution. > - The lower stack adds remote Codex execution and the task workspace. > - Operators need to configure Codex safely and inspect provider traces. > - Unsupported providers must not appear as runnable choices. > - This pull request adds Codex-only administration and observability. > - The benefit is a default-off operational surface for production diagnosis. ## Linked Issues or Issue Description Refs #12640. Refs #12616. Refs #12352. Subsystem affected Agent configuration, instance experimental settings, run ledger, provider trace inspector, and administrator actions. Problem or motivation The native runner lacks one safe operator surface for Codex permissions, lifecycle, raw trace capture, and run inspection. The integration branch also contains provider choices that the production backend cannot execute yet. Proposed solution Expose only the qualified Codex controls. Keep Paperclip Developer Mode and runner preview ingress off by default. Gate raw trace actions by administrator access and existing trace authorization. Alternatives considered Exposing unfinished providers would create configurations that fail at runtime. Always-on tracing would increase sensitive data and storage risk. Roadmap alignment This work supports governed Cloud and Sandbox agents and production diagnostics. ## Stack - Base PR: #12640. - Lower PRs: #12639 and #12638. - This PR contains only its 54-file administration and observability delta. - This is the final feature PR in the Codex production stack. ## What Changed - Added Codex-only Paperclip Runner permission and lifecycle controls. - Added bounded warm idle configuration. - Kept the provider field fixed to Codex. - Added administrator-only one-run raw trace requests. - Added a persistent future-run raw trace toggle. - Added trace status, metadata, ledger, and canonical runner inspection. - Added JSON-RPC request-origin grouping and finalization lineage. - Restored the stateful PRP transcript parser and focused projection tests required by trace inspection. - Added default-off Paperclip Developer Mode. - Added Honeycomb run links for authorized developer mode. - Disabled the legacy operational skill for `paperclip_runner`. - Did not expose OpenCode, ACPX, Pi, Claude Managed, or AWS runner choices. - Did not change migrations, workflows, dependencies, or `pnpm-lock.yaml`. ## Verification - GitHub Actions will run UI tests, server tests, repository typecheck, build, browser tests, security, and policy gates. - Tests cover Codex configuration defaults and bounds, administrator trace actions, persistent settings, ledger inspection, trace lineage, and Honeycomb links. - Existing server trace authorization and retention tests remain the backend authority. - Local tests were not run. The requested verification policy uses GitHub Actions for this series. - `git diff --check runner/task-workspace-experience...HEAD` passes. - The delta contains 54 files. ## Risks - Raw provider traces can contain sensitive provider data. - Existing server authorization controls access, reveal, download, retention, and deletion. - The UI gates trace actions by administrator access and developer mode. - All new instance settings remain off by default. - Fresh Paperclip Runner configuration remains Codex-only. - Direct adapters and legacy task behavior do not change in this PR. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI Codex with GPT-5.6. The work used high-reasoning agent mode, repository tools, GitHub tools, and parallel code-audit agents. ## 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 or instance-local Paperclip issues or links - [x] My branch name describes the change and contains no internal Paperclip ticket id - [ ] 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 risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-01 03:41:23 -05:00
Dotta	39206c0096	feat(ui): complete the task workspace (#12640 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The task page is the main place where people guide and review agent work. > - Native runner events already project into the existing task chat on the lower stack. > - The larger task workspace must support those events without breaking direct adapters. > - Legacy questions, final replies, empty transcripts, and classic controls must keep their behavior. > - This pull request completes the provider-neutral task workspace experience. > - The benefit is one coherent task surface for native and direct execution paths. ## Linked Issues or Issue Description Refs #12639. Refs #12617. Refs #12352. Subsystem affected Task chat, task detail, side panels, interaction forms, and transcript presentation. Problem or motivation The task page does not provide one complete workspace for live activity, plans, questions, queued guidance, files, and documents. Earlier native UI work also exposed compatibility risks in legacy question and reply paths. Proposed solution Add the task workspace components and provider-neutral protocol presentation. Keep runner-only controls behind runtime facts. Preserve all direct-adapter composer, transcript, interaction, and finalization behavior. Alternatives considered A separate runner page would duplicate task behavior. Replacing legacy transcript logic would create unnecessary adapter regressions. Roadmap alignment This work supports the unified task experience and the Cloud and Sandbox agents milestone. ## Stack - Base PR: #12639. - Lower PR: #12638. - This PR contains only its 119-file UI delta against `runner/remote-wss-transport`. - The next stack PR adds administrator and observability controls. ## What Changed - Added a reusable task workspace side panel for files and documents. - Added provider-neutral cards for tools, plans, questions, protocol activity, and progress. - Added queued guidance and richer composer state. - Added compact and expanded interaction presentation. - Added live activity, thinking, usage, recovery, and final reply presentation. - Added document annotations and task deep links. - Added bounded question validation and response handling. - Preserved native runner event projection from master. - Preserved legacy channel-less replies and explicit final reply precedence. - Preserved direct-adapter and classic-interface controls. - Did not change server execution selection, Rust code, migrations, workflows, or `pnpm-lock.yaml`. ## Verification - GitHub Actions will run UI tests, repository tests, typecheck, build, browser tests, security, and policy gates. - Tests cover active, settled, empty-transcript, interaction, queued-message, plan, question, file, document, and classic-interface states. - Compatibility tests cover direct adapters and native runner projection together. - Local tests were not run. The requested verification policy uses GitHub Actions for this series. - `git diff --check runner/remote-wss-transport...HEAD` passes. - The delta contains 119 UI-only files. ## Risks - This is a large task-page change. - Most files are new focused components and tests. - Shared transcript code keeps the lower native projection and legacy direct-adapter fallbacks. - Runner-only controls use adapter and runtime facts. - No execution path or rollout flag changes in this PR. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI Codex with GPT-5.6. The work used high-reasoning agent mode, repository tools, GitHub tools, and parallel code-audit agents. ## 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 or instance-local Paperclip issues or links - [x] My branch name describes the change and contains no internal Paperclip ticket id - [ ] 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 risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-01 02:44:19 -05:00
Dotta	0a422fda52	feat(runner): add remote execution substrate (#12638 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip Runner gives native runs a durable and governed execution path. > - The current native path runs on the control-plane host. > - Remote environments need an authenticated execution-target contract. > - The contract must not change direct adapters or enable new runtimes by default. > - This pull request adds the remote execution substrate and Daytona ingress. > - The benefit is a bounded base for later remote runner transport work. ## Linked Issues or Issue Description Refs #12616. Refs #12352. Subsystem affected Cross-cutting. This change touches runner transport, server orchestration, plugin contracts, and shared settings. Problem or motivation Native execution cannot resolve an authenticated runner ingress through a remote environment. The server also lacks one provider-neutral contract for remote execution targets. Proposed solution Add a default-off runner preview ingress capability. Add transport-neutral runner connectivity. Add remote execution target and lifecycle handling. Add a Daytona ingress implementation with redacted credentials. Alternatives considered A provider-specific server path would duplicate orchestration and authorization. A public endpoint without an environment contract would weaken the trust boundary. Roadmap alignment This work supports the Cloud and Sandbox agents milestone. It also supports self-healing runs and governed tool access. ## What Changed - Added execution-target traits for local, SSH, and sandbox environments. - Added plugin RPC contracts for runner ingress endpoints. - Added authenticated Daytona preview ingress. - Added transport-neutral PRP outbound connections. - Added remote runner artifact verification and fail-closed provider selection. - Added bounded native session resume, cancellation, and lifecycle recovery. - Preserved Codex-only selection for fresh experimental runner starts. - Preserved all direct adapter execution and finalization paths. - Removed stale Pi provider-pack requirements that security review rejected. - Kept the rollout controls off by default. - Did not change pnpm-lock.yaml, Cargo, database migrations, or GitHub workflows. ## Verification - GitHub Actions will run the repository test, typecheck, build, security, and policy gates. - Focused tests cover ingress validation, redaction, execution targets, remote lifecycle, cancellation, resume, and legacy adapter selection. - Local tests were not run. The requested verification policy uses GitHub Actions for this series. - `git diff --check origin/master...HEAD` passes. - The diff contains 52 files. ## Risks - Remote execution crosses a trust boundary. - The implementation validates target capabilities, artifact digests, provider-pack pins, and connection metadata. - The feature remains default-off. - Fresh native selection remains Codex-only. - Existing direct adapters remain on the legacy path. - This PR does not yet make remote Codex runnable. The next PR adds the Rust WSS and TLS transport. ## Model Used OpenAI Codex with GPT-5.6. The work used high-reasoning agent mode, repository tools, GitHub tools, and parallel code-audit agents. ## 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 or instance-local Paperclip issues or links - [x] My branch name describes the change and contains no internal Paperclip ticket id - [ ] 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 risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-01 01:29:06 -05:00
Dotta	0b73ebb86c	Fix managed OAuth catalog activation (#12623 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Apps system gives agents governed access to external services > - The managed OAuth callback discovers provider tools before it activates a grant > - Fresh managed connections kept every discovered tool in quarantine > - The Apps page also counted disabled tools as available actions > - This pull request makes setup activation atomic and keeps later catalog changes quarantined > - The benefit is a usable catalog after consent without weakening reauthorization safeguards ## Linked Issues or Issue Description N/A — no public GitHub issue exists for this follow-up. Related merged work: [#12619](https://github.com/paperclipai/paperclip/pull/12619) and [paperclip-cloud #319](https://github.com/paperclipai/paperclip-cloud/pull/319). What happened? A fresh Paperclip-managed OAuth connection discovered the correct Google Workspace tools, but it left every allowed tool in quarantine. The Apps page then reported zero actions for write profiles and counted disabled actions for read profiles. Expected behavior A fresh or revived managed connection must remain disabled until Paperclip stores credentials, discovers the catalog, reviews the profile allowlist, installs default policies, and activates the connection. A later reauthorization must preserve user choices. A later catalog change must quarantine new or changed tools. Steps to reproduce 1. Connect a managed Google Workspace write profile. 2. Complete provider consent and return through the instance callback. 3. Open the connection in Apps. 4. Observe that the connection is active but the allowed actions remain quarantined. Paperclip version or commit Commit `c7ebc089c` from merged pull request #12619. Deployment mode Self-hosted local development through Tailscale HTTPS. The same callback logic applies to Cloud-hosted instances. Installation method Built from source with pnpm. Agent adapter(s) involved Not adapter-specific. This change affects the core Apps and tool-access paths. ## What Changed - Kept fresh and revived managed connections in the draft state until catalog finalization succeeds. - Added a managed-draft refresh option that quarantines discovery results without changing generic draft behavior. - Activated reviewed profile tools, created bindings, and installed ask-first policies in the existing finalization transaction. - Preserved custom profiles, bindings, archived state, and policies during ordinary reauthorization. - Kept new or changed tools quarantined after activation and kept out-of-profile tools disabled. - Counted only active catalog entries as available actions in the Apps page. - Added retry, revival, reauthorization, policy, profile, and UI regression coverage. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` — passed, 208 tests. - `pnpm --filter @paperclipai/ui exec vitest run src/pages/apps/AppDetail.test.tsx` — passed, 52 tests. - Server and UI typechecks passed. - `pnpm build` — passed on the final tree. - `pnpm check:token-gates` — passed. - `git diff --check` — passed. - Browser walkthrough — passed for all 16 enabled Google Workspace profiles through the staging Cloud broker and a self-hosted Tailscale HTTPS instance. Every final connection became active and exposed at least one allowed action. - `pnpm test:run` — the changed suites passed. The shared live-QA environment caused unrelated workspace-runtime concurrency and cleanup failures, so hosted CI is the clean-environment authority for the full suite. ## Risks - The change affects managed OAuth only. Customer-owned OAuth setup keeps its current behavior. - A failed initial finalization now leaves a safe draft that the callback can retry. - An ordinary active reauthorization does not rebuild defaults, so existing user policy remains intact. - There are no database migrations and no public API 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.6, with reasoning, repository tools, browser control, code execution, test execution, and parallel subagent review. The effective context window was managed by the Codex task 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 the changed suites 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	2026-08-31 20:40:12 -05:00
DottaandPaperclip	a7e6b818e9	feat(apps): add Paperclip Cloud managed OAuth connector (#12600 ) ## Thinking Path > - Paperclip lets operators give governed tools to AI agents. > - Connected Apps already support provider OAuth and personal connection grants. > - Some providers require one stable callback and do not support dynamic client registration. > - Self-hosted Paperclip instances can run at private or changeable origins. > - Paperclip Cloud can provide the stable callback while each instance keeps its durable provider credentials. > - This pull request adds the instance side of that managed OAuth protocol and keeps customer-created clients available. > - The benefit is a safe path to one-click Workspace connections for hosted and enrolled self-hosted instances. ## Linked Issues or Issue Description Subsystem affected Cross-cutting. This change updates the server, Apps UI, shared app definitions, and connection documentation. Problem or motivation Some OAuth providers require a pre-registered callback and provider-owned client. An arbitrary self-hosted Paperclip origin cannot use that client callback directly. Paperclip ID must also stay limited to product identity instead of resource authorization. Proposed solution Use the existing Paperclip Cloud application as the fixed callback broker. Enroll each instance to an exact origin and separate Ed25519 and X25519 keys. Bind every request and sealed envelope to the instance, environment, user, company, provider, profile, and exact scope set. Store durable provider credentials only in the originating instance vault. Alternatives considered Customer-created OAuth clients remain available as the independent fallback. A generic redirect relay was rejected because it would allow caller-selected destinations and scopes. Paperclip ID was rejected as the broker because it is the identity boundary. A new service was rejected because the existing Cloud application already owns customer login and the public callback origin. Roadmap alignment This work extends the shipped MCP Tool Gateway and Apps milestone. It also supports the Connected Apps and Cloud deployments roadmap items. Companion Cloud implementation: https://github.com/paperclipai/paperclip-cloud/pull/312 The duplicate search found no related open Paperclip PR or issue. ## What Changed - Add a `paperclip_cloud_connector` client with signed requests, exact profile and scope bindings, and X25519-sealed credential handling. - Add explicit self-hosted enrollment with owner-only instance key storage and exact HTTPS origins. - Route managed Google Workspace setup through Paperclip Cloud and preserve customer-created OAuth clients. - Keep broker claims retryable until the local vault transaction commits. - Keep managed Google per-profile removal local-only to avoid client-wide provider revocation. - Add setup status to the Connections page and retain the Paperclip ID names as compatibility aliases. - Document the trust boundaries, enrollment, callback, refresh, removal, and rollout flows. ## Verification - `pnpm -r typecheck` - `pnpm --filter @paperclipai/shared exec vitest run src/app-definitions.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/services/paperclip-cloud-connector.test.ts src/services/paperclip-cloud-connector-enrollment.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts -t 'brokered Gmail OAuth\|brokered OAuth state'` - `pnpm --filter @paperclipai/ui exec vitest run src/pages/apps/Connections.test.tsx` - `pnpm check:token-gates` - `pnpm build` - The full stable test runner also reproduced existing macOS workspace, skill-discovery, and listener fixture failures outside the changed paths. GitHub Linux CI is the authoritative full-suite result. ## Risks - The managed flow depends on https://github.com/paperclipai/paperclip-cloud/pull/312. Real provider profiles stay disabled until Cloud deploys that protocol and the provider approves the managed client. - A Cloud outage blocks new authorization and refresh. Existing access tokens continue to work until expiry. - Managed Google profile removal only deletes the local grant. This avoids invalidating the user's other profiles that share the managed Google client. - Legacy `paperclip_id_connector` records require a reconnect after their current access tokens expire. Old Paperclip ID keys and refresh tokens are not sent to Paperclip Cloud. > 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.6 (Codex). Agentic coding, tool use, code execution, and subagents were enabled. The context-window size is not exposed in this session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-31 14:34:46 -05:00
DottaandPaperclip	39eafad47d	test(e2e): shorten and split Smoke Lab coverage (#12506 ) ## Thinking Path > - Paperclip uses browser tests to protect critical operator flows. > - The trusted pull request workflow runs the E2E catalog on three existing runners. > - Smoke Lab was one 168-second spec, so the shard scheduler could not divide it. > - The spec also repeated service-start calls, page loads, and full-page screenshots. > - This pull request removes that repeated work and divides the scenario catalog into two independent specs. > - The benefit is a shorter Smoke Lab run and a balanced E2E lane without more AWS capacity. ## Linked Issues or Issue Description Refs: #10629 What existing behavior does this improve? This improves the trusted pull request E2E lane and its Smoke Lab Playwright coverage. Current behavior Smoke Lab is one indivisible 168-second CI spec. It starts services for every scenario, loads the same evidence page twice, and captures a full-page success screenshot for all 56 lifecycle steps. Proposed behavior Start Smoke Lab services once per spec. Keep the per-scenario fixture reset. Capture one representative success screenshot per scenario and keep every failure screenshot. Run P1–P4 and P5–P7 as separate specs so the existing duration-aware scheduler can put them on different runners. Reason and benefit The optimized lifecycle reduced local Smoke Lab wall time from 57.68 seconds to 37.04 seconds. This is a 35.8% reduction. The two halves also let the existing three runners target about 125, 124, and 124 seconds of recorded spec work instead of about 168, 125, and 124 seconds. Breaking changes None. The same seven scenarios and eight lifecycle steps still run. The result API still records every step. Successful non-connect steps no longer attach redundant screenshots. ## What Changed - Reused one Smoke Lab service start within each spec while retaining isolated fixture installation for every scenario. - Removed the duplicate catalog evidence navigation. - Reduced success screenshots from 56 to 7 while retaining screenshots for every failed step. - Split the shared lifecycle runner into P1–P4 and P5–P7 specs. - Mark each successful split result as partial and keep dashboard health amber until one run covers the full catalog. - Updated the duration manifest and contributor docs for the split. ## Verification - `pnpm -r typecheck` passed on Node.js 24.20.0. - `pnpm build` passed on Node.js 24.20.0. - `node --test scripts/__tests__/e2e-shard.test.mjs` passed 9 tests. - `pnpm exec vitest run ui/src/pages/tools/smoke-lab-matrix.test.ts` passed 8 tests. - Both split specs passed together on Node.js 24.20.0 after the review fixes: 2 passed in 35.7 seconds; shell wall time was 36.86 seconds. - The pre-change Smoke Lab baseline passed with a 57.68-second shell wall time. The optimized unsplit A/B run passed with a 37.04-second shell wall time. - The full local E2E catalog passed 44 tests and skipped 2 tests. One existing `pipelines-tutorial-flow.spec.ts` assertion failed again when run alone. - The broad local unit run reproduced failures in untouched workspace-runtime suites. Typecheck, build, shard tests, and all changed browser coverage pass. CI remains the authoritative full-suite result. ## Risks - The split duration weights use the measured local reduction and the previous 168-second CI weight. They should be refreshed after two real pull request runs. - Service state is shared within each half. Fixture installation still runs before every scenario to reset connection, policy, and catalog state. - Each half records passed execution with partial coverage. Dashboard health recognizes the partial flag and stays amber because no single runner covers the full catalog. A failed half still records failed/red. - Fewer success screenshots reduce redundant artifacts. Every scenario keeps its connect screenshot, and every failure still captures evidence. > 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. The exact deployment ID and context window are not exposed in this session. The model used agentic reasoning, code editing, shell execution, browser testing, and GitHub tools. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-31 10:15:39 -05:00
DottaandPaperclip	9e4be0e60c	fix(ui): prevent false agent instruction saves (#12502 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Operators edit each agent instruction bundle in the agent detail page > - The rich Markdown editor can normalize content and emit an onChange event while it mounts > - Paperclip treated that editor event as a user edit and retained the dirty state after the tab unmounted > - This pull request accepts rich-editor changes only after real user interaction and clears shared edit state when the instructions tab closes > - The benefit is that opening instructions or moving between agent tabs no longer shows false save controls or navigation warnings ## Linked Issues or Issue Description What happened? Opening an agent Instructions page could mark the page as edited without user input. The page showed Save and Cancel controls and warned about unsaved changes during unrelated tab navigation. The shared edit callbacks could remain active after the Instructions tab unmounted. Expected behavior Opening an instruction file must not create a draft. Save controls and navigation warnings must appear only after a user changes content. Leaving the Instructions tab must clear its shared dirty, saving, save, and cancel state. Steps to reproduce 1. Open an agent Instructions tab with a Markdown entry file. 2. Do not edit the file. 3. Move to another agent tab or navigate away. 4. Observe false save controls or an unsaved-changes prompt. Paperclip version or commit Current `master` before this change. Deployment mode Self-hosted server and local development. ## What Changed - Ignore rich Markdown editor normalization events until keyboard, pointer, paste, input, drop, or before-input interaction occurs. - Reset the interaction guard when the selected file, agent, or persisted content changes. - Clear the parent dirty, saving, save, and cancel state when the Instructions tab unmounts. - Add regression tests for mount normalization and cross-tab state cleanup. ## Verification - `pnpm --filter @paperclipai/ui exec vitest run src/pages/AgentDetail.instructions.test.tsx src/pages/AgentDetail.liveRun.test.ts src/pages/AgentDetail.progress.test.ts src/components/MarkdownEditor.test.tsx` — 76 tests passed. - `pnpm -r typecheck` — passed. - `pnpm build` — passed. - `pnpm test:run` — the relevant UI tests passed. The local full runner reproduced unrelated workspace-runtime failures present on `master`; GitHub CI is the authoritative isolated full-suite gate. - `pnpm check:token-gates` — the changed files are clean. The command reports nine existing color literals in `ui/src/components/onboarding/PillGuy.tsx` from `master`. ## Risks - Low risk. The change affects only local instruction-editor dirty-state tracking. - The interaction guard covers keyboard, pointer, paste, input, drop, and before-input events. - There are no API, database, migration, or visual design 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 family. The deployment model identifier and context-window size are not exposed in this session. The agent used reasoning, repository tools, shell execution, and test execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-30 08:23:35 -05:00
Dotta	a560b48d6d	feat(apps): refine Postman and Shopify setup (#12357 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Apps give those agents governed access to external tools. > - Provider catalogs must match each provider's current protocol and credential contract. > - Postman method labels and API-key placement were outdated. > - Shopify now offers a UCP commerce endpoint that needs a managed agent-profile argument. > - This pull request updates both providers and documents the complete connection-authoring workflow. > - The benefit is accurate setup, safer runtime defaults, and a repeatable provider review process. ## Linked Issues or Issue Description Refs #11965 This is stack 10 of 11. It depends on stack 9 and preserves the final catalog work recovered from #11965. Related: #5904 covers Shopify skill routing. This pull request covers the Apps connection contract instead. ## What Changed - Update Postman hosted MCP methods, capability choices, default selection, and bearer-token placement. - Add Shopify UCP commerce and Storefront compatibility methods with public-store prerequisites. - Inject the reviewed Shopify UCP agent profile at runtime and remove that managed field from user input schemas. - Classify Shopify checkout completion and cancellation as destructive actions. - Expand the connection authoring runbook from provider research through verification and pull request handoff. - Add focused shared, server, and UI coverage. - Make the approved-execution waiter phase-aware so slow preparation cannot consume the provider execution timeout and grace period. - Settle legacy pre-execute-on-approve requests and invocations as failed, clear their stale idempotency key, and allow a fresh governed approval instead of leaving work stuck in `executing`. ## Verification - `pnpm exec vitest run packages/shared/src/app-definitions.test.ts server/src/__tests__/tool-access-service.test.ts ui/src/pages/apps/AppsConnect.test.tsx -t "Postman\|Shopify\|normalizeConnectionMethodConfig\|classifyRisk"` (16 passed) - `pnpm exec vitest run server/src/services/approved-execution-wait.test.ts` (4 passed) - `pnpm exec vitest run server/src/__tests__/tool-gateway.test.ts -t "enforces policy, approvals, retries, rate limits, and company boundaries for connected remote MCP calls"` (1 passed) - `pnpm exec vitest run server/src/__tests__/tool-gateway-service.test.ts` (21 passed; includes legacy approval settlement and fresh-approval recovery) - `pnpm --filter @paperclipai/server typecheck` - `pnpm check:token-gates` - `pnpm -r typecheck` - `pnpm build` ## Risks - Shopify UCP calls now include a Paperclip-managed agent profile that overrides caller input at the same path. - Postman EU credentials now use the hosted MCP server's bearer-token contract instead of the general REST API header. - The catalog generator and checked-in definitions change together to prevent regeneration drift. - Approved execution preparation has an explicit two-minute bound; provider execution retains its own 65-second timeout and persistence grace starting from durable provider start. - Legacy approvals created before execute-on-approve are intentionally terminalized and must be requested again under the current signed contract. > I checked `ROADMAP.md`. This provider update does not duplicate planned core work. The related open Shopify PR addresses skill routing, not Apps connections. ## Model Used OpenAI Codex, GPT-5. The runtime exact model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change 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	2026-08-29 12:08:35 -05:00
DottaandPaperclip	c90d904779	feat(apps): add connection intent setup experience (#12347 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The backend now turns agent requests into durable connection intents. > - Operators need a clear path to inspect, configure, and finish those requests. > - The experience must preserve identity, agent access, and interrupted setup state. > - This pull request adds the connection intent setup experience across the app UI. > - The benefit is one guided flow from agent request to governed connection. ## Linked Issues or Issue Description Refs #11965 This is stack 9 of 11. It depends on stack 8 and replaces another reviewable part of #11965. ## What Changed - Add connection intent cards and setup flow integration. - Add browse, connection, app detail, and sidebar experience updates. - Preserve exact draft identity and access choices across resume and OAuth recovery. - Add focused UI, architecture, policy, and end-to-end coverage. - Keep transient retained-connection lookup failures retryable instead of misclassifying them as missing targets. - Align the dark-mode E2E contract with the intentionally hidden Gateways and Profiles sidebar tabs. ## Verification - `pnpm -r typecheck` - Focused UI result: 372 tests passed across 20 files. - AppsConnect regression suite: 80/80 passed, including failed connection and application lookups during retained reconnect. - `pnpm --filter @paperclipai/ui exec vitest run src/components/AppsSidebar.test.tsx` (1 passed) - `pnpm check:token-gates` - `pnpm --filter @paperclipai/db check:migrations` - `pnpm build` ## Risks - An interrupted OAuth flow can leave a durable draft that needs resume. - The UI resumes the exact draft and keeps its identity and agent access settings. - Retained reconnect retries refetch connections and applications together to avoid mixing partial snapshots. - Gateways and Profiles remain route-accessible but intentionally absent from the sidebar until their existing ship gate is lifted. - The change does not add a database migration. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have linked the public source pull request with `Refs #` - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:35 -05:00
Dotta	d387cc0ff0	feat(connections): add managed external MCP connectors (#12346 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Connection intents need secure provider implementations to complete setup. > - Some providers use managed OAuth or external credential brokers. > - Those tokens must stay out of durable Paperclip state and fail closed when refresh fails. > - This pull request adds managed connector backends and the required storage contract. > - The benefit is safer provider setup with governed credential lifecycles. ## Linked Issues or Issue Description Refs #11965 This is stack 8 of 11. It depends on stack 7 and replaces another reviewable part of #11965. ## What Changed - Add managed Google Workspace and external connector backends. - Add Vercel Connect support without storing provider bearer tokens. - Add replay-safe migration 0232 and its generated snapshot. - Fail closed and clear stale token bindings when organization OAuth refresh needs reauthorization. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - Result: 194 tests passed. - `pnpm --filter @paperclipai/db check:migrations` - `pnpm build` - `pnpm exec vitest run --project @paperclipai/server server/src/services/remote-url-credentials.test.ts` (5 passed, including URL userinfo vault extraction) ## Risks - Broker metadata errors can block provider setup. - OAuth refresh failure disables the shared organization connection until reauthorization. - Migration 0232 is generated, ordered after 0231, and safe to replay. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have linked the public source pull request with `Refs #` - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [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	2026-08-29 12:08:34 -05:00
DottaandPaperclip	b3343dbd64	feat(connections): add self-serve intent runtime (#12345 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agents need a governed way to request app connections during issue work. > - The catalog now describes the available providers and setup methods. > - A request must become a durable, company-scoped intent before an operator acts on it. > - This pull request adds that intent runtime across server, agent, CLI, and shared contracts. > - The benefit is a safe bridge from agent need to operator-approved setup. ## Linked Issues or Issue Description Refs #11965 This is stack 7 of 11. It depends on stack 6 and replaces another reviewable part of #11965. ## What Changed - Add connection intent types, validation, service logic, and routes. - Add agent runtime tools and CLI support for connection requests. - Add issue-thread interaction support for connection intents. - Add runtime, route, adapter, and contract tests. - Hold the final resolved-continuation row lock through asynchronous adapter preparation until an actual process spawn, so parking or reassignment cannot cross that boundary. - Report Hermes Gateway's first remote run request through the shared dispatch hook so the resolved-intent lock is released at the true dispatch boundary. - Revalidate the addressed user's live non-viewer membership and connection-management authority for every intent mutation, including OAuth completion. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - Result: 176 tests passed. - `pnpm build` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/heartbeat-stale-queue-invalidation.test.ts` (32 passed; includes non-process dispatch lock-release coverage) - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/connection-intents-service.test.ts -t "addressed-user mutation"` (1 passed) - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/tool-access-service.test.ts -t "binds OAuth callback completion to the initiating board session"` (1 passed) - `pnpm --filter @paperclipai/hermes-paperclip-adapter test -- src/gateway/server/execute.test.ts` (23 passed; includes dispatch-hook ordering and exactly-once coverage) - `pnpm --filter @paperclipai/hermes-paperclip-adapter typecheck` ## Risks - A malformed intent could create an unusable operator request. - Validators and company checks reject invalid or cross-company requests. - The final continuation gate holds the issue row lock through adapter preparation until process or remote dispatch; later operator changes use the normal active-run interruption path. - The change does not add a database migration. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have linked the public source pull request with `Refs #` - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:34 -05:00
DottaandPaperclip	fcb2e99e8f	feat(apps): expand the self-serve connection catalog (#12344 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - A useful app store needs accurate and selectable provider definitions. > - Local brand assets now cover the expanded provider set. > - Provider methods differ in transport, authentication, ownership, and required scope. > - This pull request expands the catalog and encodes those provider contracts. > - The benefit is a larger self-serve store with explicit setup choices. ## Linked Issues or Issue Description Refs #11965 This is stack 6 of 11. It depends on stack 5 and replaces another reviewable part of #11965. ## What Changed - Add and update provider definitions for the self-serve catalog. - Add Google Workspace connection methods and capability profiles. - Add catalog generation, ingestion, URL matching, and contract tests. - Update legacy key tests to use a provider that still uses header credentials. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - Result: 164 tests passed. - `pnpm build` ## Risks - An incorrect provider definition can offer the wrong setup method. - Contract tests verify transport, authentication, and provider URL behavior. - The change does not add a database migration. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Refs #` or (b) described the issue in this pull request - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:34 -05:00
DottaandPaperclip	10c4902ffc	feat(apps): add local connection brand assets (#12343 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The app store needs stable provider marks that do not depend on remote image hosts. > - The connector layer adds many recognizable services. > - Local assets must work in light and dark themes and follow the design token gate. > - This pull request adds the provider asset set and its rendering support. > - The benefit is fast and consistent app identification across the UI. ## Linked Issues or Issue Description Refs #11965 This is stack 5 of 11. It depends on stack 4 and replaces another reviewable part of #11965. ## What Changed - Add local provider logos for the connection catalog. - Add light and dark asset selection where providers need it. - Add deterministic fallback behavior and UI tests. - Document the fixed brand-color allowlist in the token gate. ## Verification - `pnpm -r typecheck` - `pnpm check:token-gates` - `pnpm --filter @paperclipai/ui exec vitest run src/pages/apps/AppLogo.test.tsx` - `pnpm build` ## Risks - A missing asset path can show the deterministic letter fallback. - Brand SVG colors use the documented asset allowlist because provider marks cannot use product theme tokens. - The change does not add a database migration. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Refs #` or (b) described the issue in this pull request - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:33 -05:00
DottaandPaperclip	6244e4cf32	feat(apps): add Composio and Gmail connectors (#12342 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - App connections need both direct providers and managed provider hubs. > - The grant layer now defines safe credential ownership. > - Composio needs parent and child connection lifecycle rules, and Gmail needs governed setup. > - This pull request adds both connector families on the grant foundation. > - The benefit is broader app access without weakening credential isolation. ## Linked Issues or Issue Description Refs #11965 This is stack 4 of 11. It depends on stack 3 and replaces another reviewable part of #11965. ## What Changed - Add Composio parent and child connection support. - Add Gmail connection setup and governance. - Preserve credential paths and remove duplicate binding declarations. - Cascade Composio pause and restore actions to child connections. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - Result: 164 tests passed. - `pnpm build` ## Risks - Parent lifecycle changes can affect every Composio child. - The service restores only children whose provider accounts remain active. - Credential binding paths are normalized before secret resolution. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:33 -05:00
DottaandPaperclip	20ccf3f476	feat(apps): add connection grants and delegated identities (#12341 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - External tools need explicit identity and access boundaries. > - Shared connection credentials cannot represent every user-scoped use case. > - Grants must stay company-scoped and support safe delegation. > - This pull request adds connection grants, identity rules, and their database contract. > - The benefit is durable control over which identity an agent may use. ## Linked Issues or Issue Description Refs #11965 This is stack 3 of 11. It depends on stack 2 and replaces another reviewable part of #11965. ## What Changed - Add company and user connection grants. - Add delegated identity and membership rules. - Synchronize database, shared, server, and UI contracts. - Register the grant-member replacement route in the OpenAPI surface in the same layer that mounts it. - Add migration 0231 with replay-safe guards and coverage. ## Verification - `pnpm -r typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/openapi-routes.test.ts` (5 passed) - `pnpm --filter @paperclipai/db check:migrations` - `pnpm build` ## Risks - Incorrect grant selection could expose the wrong credential scope. - The service enforces company and subject boundaries before credential use. - Migration 0231 is generated, ordered after 0230, and safe to replay. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either linked a public issue or pull request with `Refs #` - [x] I have not referenced internal or instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:33 -05:00
DottaandPaperclip	b51112798f	feat(apps): improve gateway and workspace connection UX (#12340 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - App connections must work in both the operator UI and agent tool gateway. > - The first stack layer adds secure remote connections. > - Operators still need clear setup, test, and recovery states. > - This pull request adds the gateway behavior and the workspace connection experience. > - The benefit is a connection flow that is easier to understand and recover. ## Linked Issues or Issue Description Refs #11965 This is stack 2 of 11. It depends on stack 1 and replaces another reviewable part of #11965. ## What Changed - Improve remote tool gateway connection behavior. - Add clearer app setup, test, and recovery states. - Add focused server and UI tests for the new paths. - Keep the diff isolated from later identity and catalog work. - Stabilize DNS-pinned remote HTTP protocol fixtures and the managed-runtime public-origin fixture for this independently tested layer. ## Verification - `pnpm -r typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` (150 passed) - `pnpm test:run` - `pnpm check:token-gates` - `pnpm build` ## Risks - Gateway errors now surface through new user-facing states. - A stale connection can require a new setup attempt. - The change does not add a database migration. - The injected HTTP transport and public URL are test-only fixtures; production DNS pinning and runtime behavior are unchanged. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links - [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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:32 -05:00
DottaandPaperclip	cabc9146d0	feat(apps): add secure remote MCP and PostHog setup (#12339 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Apps give those agents governed access to external tools. > - Remote MCP setup needs secure endpoint validation and durable credentials. > - PostHog needs both browser sign-in and personal API key setup paths. > - This pull request adds the shared remote MCP foundation and the PostHog definition. > - The benefit is a secure and reusable base for later app connection work. ## Linked Issues or Issue Description Refs #11965 This is stack 1 of 11. It replaces the first reviewable part of #11965. ## What Changed - Add guarded remote MCP setup and credential handling. - Add PostHog OAuth and API key connection methods. - Add focused server, shared contract, and UI coverage. - Keep the migration replay-safe and idempotent. - Give the late-close security regression the same 10-second CI headroom as the adjacent real-timer handshake test. - Synchronize fake-timer handshake tests at the exact ensure-session boundary so real filesystem setup cannot race the fake deadline. - Drive PTY overflow coverage only after listener registration so scheduling cannot reorder the test fixture. ## Verification - pnpm exec vitest run packages/adapter-utils/src/acpx-engine/execute.test.ts server/src/__tests__/plugin-worker-manager.test.ts (220 passed; affected cases also passed five focused stress repetitions) - `pnpm exec vitest run packages/adapter-utils/src/acpx-engine/execute.test.ts -t "never leaks a sandbox-provided value from a late close rejection into logs or the result"` (1 passed) - `pnpm exec vitest run packages/adapter-utils/src/acpx-engine/execute.test.ts -t "never promotes a late ensureSession resolution\|closes a late-resolving real handle exactly once"` (2 passed) - `pnpm -r typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - `pnpm --filter @paperclipai/db check:migrations` - `pnpm build` ## Risks - Remote endpoint validation can reject configurations that previously passed without checks. - OAuth configuration errors can block setup until the operator corrects the provider settings. - The migration uses guarded statements so repeated execution is safe. - The test-only synchronization changes do not affect runtime behavior; they remove filesystem/fake-clock and listener-registration races observed under parallel CI load. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-29 12:08:32 -05:00
Devin Foley	bc1a21564f	Remove the company brand color and per-company attachment limit (#12291 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A company is the top-level container, and the company General page holds its settings > - Two of those settings did almost nothing: the brand color only tinted the generated company icon, and the attachment size limit sat under the deployment-level `PAPERCLIP_ATTACHMENT_MAX_BYTES` cap that already bounded every upload > - A setting that changes one icon hue, and a setting that can only lower a limit the operator already set, are not worth the page space or the code that carries them > - This pull request deletes both settings from the UI, the validators, the API contract, the server, and the database > - With the deployment cap as the only limit left, the message a person sees when an upload is rejected has to name that limit in terms they can act on, so the raw byte count becomes a human-readable size > - The benefit is a shorter company General page for every deployment, one attachment limit instead of two, and less code between an upload and its ceiling ## Linked Issues or Issue Description No existing issue. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. What existing behavior does this improve? The company General page (`/company/settings`), the `PATCH /api/companies/{companyId}` and `PATCH /api/companies/{companyId}/branding` request contracts, and the attachment upload limit on task, case, and company-import uploads. Subsystem affected Cross-cutting: `ui/`, `server/`, `packages/shared`, `packages/db`. Current behavior The company General page shows an "Appearance" section with three controls: Logo, Brand color, and Attachment size limit. The brand color is a hex value that feeds one thing — the hue of the generated company pattern icon. Companies that never set one already get a hue derived from the company name. The attachment size limit is a per-company byte count stored on `companies.attachment_max_bytes`. Every upload path clamps it against the deployment-level `PAPERCLIP_ATTACHMENT_MAX_BYTES` cap, so the per-company value can only lower a limit the operator already chose. Proposed behavior The Appearance section keeps the Logo control only. The company pattern icon always derives its hue from the company name. Every attachment path reads the deployment cap directly, so `PAPERCLIP_ATTACHMENT_MAX_BYTES` is the single limit. An upload rejected by that limit says so in human units — "File is larger than the 10 MB limit" rather than a raw byte count. The `companies.brand_color` and `companies.attachment_max_bytes` columns are dropped, and both fields leave the company API contract. Reason and benefit Both settings ask an operator to make a decision that changes almost nothing. The brand color moves one icon hue on a page that also lets you upload a real logo, which overrides the icon entirely. The attachment limit reads as a real control but cannot raise anything, so it is a second place to look when an upload is rejected. Removing both shortens the page every deployment sees, removes a company-scoped read from the task attachment upload path, and leaves one attachment limit to reason about instead of two. Breaking changes The company API responses no longer include `brandColor` or `attachmentMaxBytes`, and `GET /api/invites/{token}` no longer includes `companyBrandColor`. `PATCH /api/companies/{companyId}/branding` is strict, so a request that sends `brandColor` now returns 400; the non-strict `PATCH /api/companies/{companyId}` schema strips it. Company packages exported by older versions still import: the portability company manifest schema is non-strict, so the retired keys are stripped and ignored rather than rejected. Companies that stored a brand color lose it — their icon reverts to the name-derived hue that every company without a color already used. ## What Changed - Removed the "Brand color" and "Attachment size limit" fields from the company General page, along with their state, dirty checks, save payload, and Save-button gating. - Removed `brandColor` and `attachmentMaxBytes` from `createCompanySchema`, `updateCompanySchema`, and `updateCompanyBrandingSchema`, and deleted the now-orphaned `DEFAULT_COMPANY_ATTACHMENT_MAX_BYTES` and `MAX_COMPANY_ATTACHMENT_MAX_BYTES` constants. - Removed both fields from the `Company` type, the portability manifest type and schema, and the `companiesApi.update` payload allowlist. - Dropped `brandColor` from `CompanyPatternIcon` and its callers, so the icon hue always comes from the company name. Deleted the now-unused `hexToHue` helper and the now-unused `pickTextColorForSolidBg` export. - Stopped emitting `brandColor` from the company service selection and from the invite-summary and invite-branding payloads in `server/src/routes/access.ts`. - Replaced `normalizeIssueAttachmentMaxBytes` with the deployment cap: task attachments, case attachments, and company import now use `MAX_ATTACHMENT_BYTES` directly. The helper is deleted. - Added `formatAttachmentSize()` next to `MAX_ATTACHMENT_BYTES` and routed every over-limit message through it, so a rejected upload names the limit in human units instead of raw bytes: `Image exceeds 10485760 bytes` becomes `Image is larger than the 10 MB limit`. Enforcement is unchanged — the same single cap, the same multer limits, the same status codes and response shapes. - Added migration `0229_drop_company_brand_color_and_attachment_max_bytes.sql` and removed both columns from the Drizzle `companies` schema. - Kept legacy imports working: the portability company manifest schema is non-strict, so older packages carrying the retired keys still import with the keys ignored. - Updated the skill API reference and the implementation spec, and pruned the token-extraction allowlist entries that the removed code made stale. ## Verification Commands run from the repository root: - `pnpm --filter @paperclipai/shared typecheck` — pass - `pnpm --filter @paperclipai/db typecheck` — pass (includes `check:migrations`, which validates the new migration number and journal entry) - `pnpm --filter @paperclipai/ui typecheck` — pass - server typecheck via `node_modules/.bin/tsc --noEmit` in `server/` — pass. `pnpm --filter @paperclipai/server typecheck` could not run locally because it builds the Rust runner first and `cargo` is not installed on this machine; the TypeScript step it wraps is the command above. - `npx vitest run packages/shared/src/validators/company.test.ts` — 6 passed - `npx vitest run server/src/__tests__/company-portability.test.ts` — 90 passed - `npx vitest run server/src/__tests__/attachment-types.test.ts server/src/__tests__/assets.test.ts server/src/__tests__/issue-attachment-routes.test.ts server/src/__tests__/company-portability.test.ts server/src/__tests__/cases-routes.test.ts` — 165 passed (the human-readable limit messages) - `npx vitest run server/src/__tests__/company-branding-route.test.ts server/src/__tests__/issue-attachment-routes.test.ts server/src/__tests__/invite-summary-route.test.ts server/src/__tests__/openclaw-invite-prompt-route.test.ts server/src/__tests__/companies-route-cross-company-authz.test.ts` — all passed - `npx vitest run cli/src/__tests__/company.test.ts cli/src/__tests__/company-delete.test.ts` — 27 passed - `npx vitest run` in `ui/` — 4425 passed, 1 pre-existing failure unrelated to this change (`OnboardingWizard.test.tsx` "renders instead of throwing when the browser denies storage access", which also fails on `master`) - `npx vitest run` in `server/` — see the note below - `node scripts/check-token-gates.mjs` — no new violations; the only reported violations are the pre-existing `PillGuy.tsx` ones present on `master` New tests added: - `packages/shared/src/validators/company.test.ts` — the create and update schemas strip the retired keys, the strict branding schema rejects `brandColor`, and the portability manifest schema accepts a legacy entry carrying both keys and drops them. - `server/src/__tests__/company-branding-route.test.ts` — `PATCH /api/companies/{companyId}/branding` returns 400 for `brandColor` and does not call the company service. - `server/src/__tests__/company-portability.test.ts` — a legacy package that declares `brandColor` and `attachmentMaxBytes` imports successfully, and neither key reaches `companies.create`. - `server/src/__tests__/issue-attachment-routes.test.ts` — the effective task attachment limit is the deployment cap, and the route no longer loads the company to size an upload. - `server/src/__tests__/attachment-types.test.ts` — `formatAttachmentSize()` renders the default cap as `10 MB`, keeps one decimal place for fractional sizes and drops a trailing `.0`, falls back to KB and bytes for small caps, steps up to GB, and never emits `NaN` for a degenerate input. - `server/src/__tests__/assets.test.ts` — the asset-image and company-logo routes both return the human-readable limit message on an over-cap upload. ## Merge with master `master` moved while this was open, and the merge needed two resolutions: - `ui/src/pages/CompanySettings.tsx`. #12243 reworded the user-facing copy from "company" to "organization", and that rewording landed inside the "Brand color" and "Attachment size limit" hints — the two fields this change deletes. Both fields are removed, so the conflicted block is dropped whole. The Logo field and every other copy change from #12243 are kept. - Migration renumbered 0228 -> 0229. #12307 landed `0228_nasty_grim_reaper`, so this migration is now `0229_drop_company_brand_color_and_attachment_max_bytes`. Its snapshot is rebuilt from master's `0228_snapshot.json` with only the two `companies` columns removed, and `meta/_journal.json` is master's journal plus a single `idx: 229` entry. `pnpm --filter @paperclipai/db check:migrations` passes. The snapshot was rebuilt by hand rather than taken from `drizzle-kit generate`, because master's `0228_snapshot.json` has drifted from master's own schema: `issue_question_response_deliveries.error_count` is created by master's 0228 SQL but missing from its snapshot, and the snapshot still carries `decision_archive_notification_outbox.error_count`. Regenerating folds both into this migration, and the resulting `ADD COLUMN error_count` would fail on a fresh database where master's 0228 already created that column. Rebuilding from master's snapshot leaves that drift exactly where it is and keeps this migration to the two column drops. The drift is pre-existing on master and is not addressed here. ## Risks - The migration is a destructive column drop. `0229_drop_company_brand_color_and_attachment_max_bytes.sql` removes `companies.brand_color` and `companies.attachment_max_bytes`. It is safe because both features are removed in the same change and nothing reads either column after it. The statements use `DROP COLUMN IF EXISTS`, matching the convention of the recent drop migrations in this repository. The drop is not reversible: a downgrade after this migration loses any stored values. - Stored brand colors are lost. A company that had set a color now renders the name-derived icon hue that every company without a color already used. No other surface changes, and an uploaded logo still overrides the icon. - API response shape narrows. `brandColor` and `attachmentMaxBytes` leave the company payloads, and `companyBrandColor` leaves the invite summary payload. A client reading those fields now sees `undefined`. The bundled UI and CLI are updated in this change. - Legacy imports are covered. Packages exported by older versions still carry both keys. The manifest schema is non-strict, so the keys are stripped rather than rejected, and a test locks that in. - The over-limit message strings changed. Anything matching on the old `... exceeds N bytes` text — a test, a script, or a client that string-matches `body.error` — needs updating. The status codes (422) and response shapes are unchanged, so structured clients are unaffected. - Attachment limits can only widen. A deployment that had lowered a company below the deployment cap now allows uploads up to the cap for that company. Lower `PAPERCLIP_ATTACHMENT_MAX_BYTES` if a smaller ceiling is needed. - Storybook visual baselines shift for the `CompanyPatternIcon` matrix story, because those fixtures had brand colors. That workflow runs only on a PR labeled `storybook-visual`, so it does not gate this PR; regenerate the baselines if the label is added. ## Model Used Claude (Anthropic), Claude Opus, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [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	2026-08-27 12:11:05 -07:00
Devin Foley	7b91fe9ea7	Hide host-path and execution-engine surfaces in managed-sandbox-only mode (#12293 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - An instance can turn on the `enableManagedSandboxOnly` feature, which hides the local environment and runs every agent in the platform-managed environment > - That feature already gated the environment pickers, the onboarding wizard, and the server-side run selection, but many other screens still showed absolute paths on the execution host and still let the user pick an execution engine > - On such an instance those controls name a filesystem the user cannot reach; a path written there is stored and then ignored, which reads as a broken control > - This pull request hides the remaining host-path and execution-engine surfaces behind the same feature, adds a server rule that refuses a project-workspace path write while the feature is on, and closes a related route gap in the isolated-workspace pages > - The benefit is that a managed instance shows no host path and no folder picker anywhere, and a write that carries a path now fails with a clear message instead of being silently discarded ## Linked Issues or Issue Description No public issue exists. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. What existing behavior does this improve? The `enableManagedSandboxOnly` instance feature, and the UI surfaces that show a host filesystem path: project properties, the new-project dialog, the project workspace and execution workspace detail pages, the workspace and task cards, plugin local folders, and the agent configuration form with its per-adapter fields. It also improves route gating for `enableIsolatedWorkspaces`. Subsystem affected Cross-cutting (`ui/` and `server/`). Current behavior When `enableManagedSandboxOnly` is on, the local environment disappears from the environment pickers and the server refuses to run an agent on the local host. Everything else stays visible. A user still sees: - the project "Local folder" row, its absolute path, and the Set/Change/Clear buttons - the "Local folder" field and its "Choose" folder picker in the new-project dialog - the "Local path" field and fact row on a project workspace - the "Paths" and "Lifecycle commands" groups on an execution workspace - the working directory on workspace cards, task properties, and runtime service rows - the plugin "Local folders" section - "Working directory (deprecated)", "Command", "Execution engine", "ACP server command", "ACP state directory", and "Agent instructions file" in the agent configuration form A path typed into any of these names a filesystem no agent on the instance uses. The project workspace API also accepts a `cwd` write and stores it. Separately, `/workspaces`, `/execution-workspaces/`, and `/projects/:projectId/workspaces/:workspaceId` render for anyone who types or bookmarks the URL, even with `enableIsolatedWorkspaces` off. Only the sidebar entry reads that flag. Proposed behavior* With `enableManagedSandboxOnly` on, none of those surfaces render. A project whose codebase came from a managed checkout keeps its one-line "Paperclip-managed folder." label and shows no path. The non-path controls stay: repo URL, branch, service URL, port, command output, ACP session mode, ACP non-interactive permissions, Codex fast mode, and the sandbox toggles. The project-workspace create and patch routes, and the nested workspace on project create, answer `422` with "This instance runs agents only in the platform-managed environment; local folders are not configurable." when the payload carries a non-null `cwd`. A `cwd: null` write still passes, so an instance that just turned the feature on can clear a stale path. With `enableIsolatedWorkspaces` off, the three workspace route groups redirect to the dashboard. Reason and benefit A control that cannot do anything is worse than a missing control: the user fills it in, saves, and gets no error and no effect. The server rule turns that silent no-op into a clear refusal. The route gate stops a feature that an instance has turned off from staying reachable by URL, which is the same standard the Cases, Pipelines, and hidden-settings pages already meet. Breaking changes None for a default instance: both flags are off by default for self-hosted and managed instances, so nothing changes unless an operator turns them on. Stored `adapterConfig` values are never cleared, so turning the feature off restores every previous value. ## What Changed - Add `ui/src/hooks/useManagedSandboxOnly.ts`, modelled on `useAppsEnabled`, for components that do not already read the experimental settings. It exposes `hideHostPaths`, which fails closed while the settings query is in flight, so a cold cache never flashes a host path before the policy resolves. Components that keep their own settings read compute the same gate from `isFetched`. - Add `managedSandboxOnly` to `AdapterConfigFieldsProps` and populate it where `AgentConfigForm` builds the adapter field props. Resolve the effective instructions-file gate once as `hideInstructionsFile \|\| hideHostPaths`, so every adapter hides that path field with no per-adapter edit. - Hide under the flag: the project "Local folder" block and its absolute-path edit panel (a managed checkout keeps its label, without the path); the new-project "Local folder" field; the project-workspace "Local path" field and fact row; the execution-workspace "Paths" and "Lifecycle commands" groups; the working directory on the workspace summary card, the task workspace card, the task properties "Folder" row, and the runtime service rows; the plugin "Local folders" section; "Working directory (deprecated)" and "Command" in the agent form; and the per-adapter "Execution engine", "ACP server command", and "ACP state directory" for `claude_local`, `codex_local`, and `gemini_local`. - Drop two working-directory fallbacks that had no gate to read: the close-workspace dialog now falls back to "No additional details", and the reuse-existing workspace label and picker subtitle fall back to a neutral phrase. - Refuse a non-null `cwd` with `422` on `POST /projects/:id/workspaces`, `PATCH /projects/:id/workspaces/:workspaceId`, and the nested workspace on `POST /companies/:companyId/projects`, following the `assertNoAgentHostWorkspaceCommandMutation` precedent on those routes. - Add `IsolatedWorkspacesRouteGate` and wrap the `/workspaces`, `/execution-workspaces/*`, and `/projects/:projectId/workspaces/:workspaceId` routes with it. - Leave the SSH "Remote workspace path" and the workspace file browser alone, with a comment explaining why. ## Verification Automated: - `pnpm --filter @paperclipai/ui exec vitest run` — 479 of 480 files pass (4455 of 4456 tests). The one failure is `OnboardingWizard.test.tsx > renders instead of throwing when the browser denies storage access`, which also fails on `origin/master` and is unrelated to this change. - `pnpm --filter @paperclipai/server exec vitest run project workspace instance-settings` — 45 of 50 files pass. Four files fail on macOS for reasons unrelated to this change: `workspace-instance-cleanup`, `workspace-runtime`, `execution-workspace-runtime-control-conflict`, and `workspace-runtime-exposure` compare `/var/...` against the resolved `/private/var/...` or bind real ports. The same files fail on a clean `master` checkout on the same machine. - `pnpm --filter @paperclipai/ui typecheck` - `tsc --noEmit` in `server/` (after `pnpm --filter @paperclipai/plugin-sdk ensure-build-deps`). The package `typecheck` script also builds the Rust runner, which needs `cargo`; it is not installed on the machine that ran this. New and extended tests: - `ui/src/adapters/managed-sandbox-only-config-fields.test.tsx` — the three adapters drop the execution engine, the ACP paths, the instructions-file path, and every "Choose" button when the flag is on, and keep the non-path controls. - `ui/src/components/AgentConfigForm.render.test.tsx` — flag-on and flag-off renders for the working directory, the command, the engine, the ACP paths, and the resolved adapter field props. - `ui/src/components/ProjectProperties.managed-sandbox.test.tsx`, `ui/src/components/NewProjectDialog.managed-sandbox.test.tsx`, `ui/src/pages/ProjectWorkspaceDetail.test.tsx`, `ui/src/components/ProjectWorkspaceSummaryCard.test.tsx`, `ui/src/components/WorkspaceRuntimeControls.test.tsx`. - `ui/src/components/IsolatedWorkspacesRouteGate.test.tsx` — redirect when off, render when on, and render nothing while the flag query is in flight. - "Still loading" cases for the project properties, the new-project dialog, the workspace summary card, the runtime service rows, and the agent configuration form, each asserting that no host path renders before the policy resolves. - `server/src/__tests__/project-workspace-managed-sandbox-routes.test.ts` — the `422` on all three write paths, the `cwd: null` pass-through, and the flag-off pass-through. Manual check to reproduce: turn on Managed Environment Only in instance experimental settings, then open a project, the new-project dialog, an agent's configuration, and a workspace page. No path, folder icon, or "Choose" button appears. Turn the setting off and each control returns with its stored value. No documentation change was needed. The operator-facing text for both settings lives in the feature catalog entry, which already states the contract this pull request now enforces across the UI. ## Risks - Low. Both flags default to off, so a default instance is unchanged. - The hidden fields are presentation only. No stored `adapterConfig` value is cleared, because an import carries adapter configuration written on another instance and clearing it would break that flow. Turning the setting off shows every previous value again. - The `422` is the one behavior change for an API caller, and only while the setting is on. `cwd: null` still passes so a stale path can be cleared. - The route gate renders nothing until the flag query settles, so an instance with isolated workspaces on never flashes a redirect. An instance with the feature off now redirects a bookmarked workspace URL to the dashboard. - Every host-path guard fails closed while the settings query is in flight, so a default instance shows those controls a moment later than before on a cold load. That is the safe direction: the alternative flashes a path a managed instance must never show. - Two path surfaces stay on purpose, each with a comment: the SSH "Remote workspace path" is a path on the user's own remote host, and the workspace file browser shows workspace-relative paths. The instance Adapters page also keeps its "Local path" install option, since that page is an instance-admin surface the hosting operator can already hide through the hidden-settings mechanism. ## Model Used Claude (Anthropic), Claude Opus, 1M context window, extended thinking, agentic tool use through Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [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	2026-08-27 11:59:14 -07:00
Devin Foley	76f7019bdf	feat(server): derive hosted-tenant issue prefixes from the company name and follow renames (#12292 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Every company has an issue prefix. It is the visible half of each task and case identifier, and a self-hosted company derives it from the name it was created with > - A hosted or managed instance does not use the create-company flow. The trusted-header auth path claims the tenant company instead > - That path minted the prefix from a hash of the stack id, and it wrote a placeholder description that nobody chose > - So a hosted company showed opaque task IDs such as `PC7F2A-14`, and a rename never changed them > - This pull request derives the prefix from the company name on that path too. It re-derives the prefix when the name changes on a managed instance, and it rewrites the stored issue and case identifiers so existing tasks follow the rename > - It also repairs each company that an earlier build claimed. The repair runs once, on the next authenticated request > - The benefit is that task IDs on a hosted instance read like the ones on a self-hosted instance, and they stay correct after a rename ## Linked Issues or Issue Description No public issue exists. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. What existing behavior does this improve? The tenant company claim in `resolveCloudTenantActor` (`server/src/middleware/auth.ts`) and the company update in `companyService.update` (`server/src/services/companies.ts`). Both decide the `issue_prefix` and the `description` of a company on a hosted or managed instance. Subsystem affected `server/` — REST API and orchestration services. One small hint was also added in `ui/`. Current behavior A self-hosted company gets its issue prefix from its name. "Acme Robotics" becomes `ACM`, and its tasks read `ACM-14`. A hosted or managed instance claims the company through the trusted-header auth path. That path wrote a different prefix: `"PC"` plus the first four hex characters of the SHA-256 of the stack id. The same path also wrote a placeholder description, `"Provisioned by ... for stack <stack id>."`. The result is a task ID such as `PC7F2A-14`. It says nothing about the company. A later rename of the company does not change it, because nothing re-derives the prefix after creation. Proposed behavior The claim path derives the prefix from the company name, exactly as the create-company flow does. It writes no description. On a managed instance, a rename re-derives the prefix. The stored issue and case identifiers move with it, so `ACM-14` becomes `NOR-14` when "Acme Robotics" becomes "Northwind Traders". A rename that keeps the same three-letter base keeps the current prefix, including any disambiguating suffix. A self-hosted instance is unchanged. A rename there still keeps the prefix the company was created with. Companies that an earlier build already claimed get a one-time repair on their next authenticated request. The repair re-derives the prefix from the current name, re-keys the identifiers, and clears the placeholder description. Reason and benefit A task ID is the primary handle for a task. People type it, paste it into chat, and read it in a URL. On a hosted instance that handle was an opaque hash, and it disagreed with the company name that the same user chose during signup. The name is the only prefix source a hosted user ever supplies, so the prefix now follows it. Breaking changes Yes, on hosted and managed instances only. A company rename now rewrites the stored issue and case identifiers. Links that carry an old identifier stop resolving after the rename. The company settings page states this before the user saves. The one-time repair applies the same rewrite once to companies that carry the old hash prefix. Self-hosted behavior does not change. ## What Changed - Added `server/src/services/issue-prefix.ts`. It holds the prefix helpers that used to live inside the `companyService` closure: `ISSUE_PREFIX_FALLBACK`, `deriveIssuePrefixBase`, `issuePrefixSuffixForAttempt`, and `isIssuePrefixConflict`. The companies service now imports them. - Added `pickAvailableIssuePrefix` to that module. It reads the prefixes in one base family and returns the first free candidate. A standalone `INSERT` can retry on a unique violation, because each failed statement is its own implicit transaction. A caller that already holds a transaction cannot, because the violation aborts the whole transaction. Such a caller picks first, then writes. - Added `rekeyCompanyIssueIdentifiers` to that module. It rewrites the prefix of the stored `issues.identifier` and `cases.identifier` values of one company in the caller's transaction, and it returns the two row counts. - `companyService.update` re-derives the prefix when the name changes on a managed instance, re-keys both tables in the same transaction, and writes a `company.updated` activity entry after the commit. - `resolveCloudTenantActor` claims the company with a name-derived prefix and a null description. The claim retries with the next suffix when the prefix is taken. - `resolveCloudTenantActor` also runs a one-time repair for companies that carry the old hash prefix. An exact-match fence on the update lets a concurrent rename win. The repair is idempotent, because its guards stop matching after it lands. - The rename takes a row lock on the company before it compares anything against it, and it re-keys from the prefix it reads under that lock. Only patch and environment facts gate the lock, so no stale read can steer the decision. Two overlapping updates would otherwise leave a company whose prefix disagrees with its own identifiers, in either direction: two renames, where the second re-keys from a prefix the first already moved; or a rename plus a stale form that resubmits the original name, where the second sees an unchanged name, skips re-derivation, and restores the old name on top of the first rename's prefix. Only a managed instance takes the lock, and only for an update that carries a name. - Both helpers compare an exact identifier head instead of a LIKE pattern. A stored prefix is data, so it must never be read as a pattern. - The company settings page shows a hint under the name field on a managed instance: renaming can change the task ID prefix. ## Verification Automated tests: ``` pnpm --filter @paperclipai/server exec vitest run \ src/services/issue-prefix.test.ts \ src/__tests__/companies-service.test.ts \ src/__tests__/cloud-tenant-company-provisioning.test.ts \ src/middleware/cloud-tenant-actor.test.ts \ src/__tests__/auth-session-route.test.ts \ src/__tests__/cloud-routes.test.ts \ src/__tests__/cloud-instance.test.ts \ src/__tests__/company-branding-route.test.ts \ src/__tests__/company-cloud-floor.test.ts \ src/__tests__/companies-route-cross-company-authz.test.ts \ src/__tests__/companies-route-path-guard.test.ts \ src/__tests__/company-portability.test.ts pnpm --filter @paperclipai/ui exec vitest run pnpm --filter @paperclipai/ui typecheck ``` New coverage: - `server/src/services/issue-prefix.test.ts` covers the derivation, the suffix ladder, the cause-chain walk of the unique-violation detector, and `pickAvailableIssuePrefix` against a stubbed select. - `server/src/__tests__/companies-service.test.ts` covers a managed rename against a real Postgres database: the prefix moves, both identifier tables are re-keyed, and the activity entry is written. It also covers a same-base rename, a collision that takes the suffixed candidate, a non-name patch, and a self-hosted rename that leaves the prefix alone. Two more tests drive the overlap cases: two concurrent renames of the same company, and a rename racing a stale form that resubmits the original name. Both assert that the surviving name's base matches the company prefix and that the stored identifiers sit on that prefix. - `server/src/__tests__/cloud-tenant-company-provisioning.test.ts` covers the claim path and the repair against a real Postgres database: a name-derived prefix, a null description, a suffixed prefix on collision, the full repair, a second pass that changes nothing, a description-only repair, and an operator-written description that the repair leaves alone. - `ui/src/pages/CompanySettingsRenameHint.test.tsx` covers the hint on a managed instance and its absence on a self-hosted instance. The `substring` cast in `rekeyCompanyIssueIdentifiers` is load-bearing and the database tests prove it. The driver binds the offset as text. Without the `::int` cast Postgres resolves the SQL-regex overload of `substring`, and every identifier becomes NULL. ## Risks - Re-keying changes existing identifiers and URLs. This is deliberate, and it happens on hosted and managed instances only. After a rename, a link that carries an old task identifier stops resolving. The settings page warns about this before the user saves. - Identifiers inside comment text are not rewritten. Only the `identifier` columns of `issues` and `cases` move. A task ID that someone typed into a comment, a description, or a document keeps the old prefix. - A lost prefix race inside the rename transaction surfaces as a conflict. The rename picks a free prefix and then writes, because a unique violation inside a transaction aborts the whole transaction. Two different companies renamed onto the same base at the same moment can still collide. The loser sees its PATCH fail with the unique violation. The write is retryable by the client, and the window is a single statement wide. Two renames of the same company no longer race: the row lock serializes them, and the second one re-keys from what the first committed. - The rename holds a row lock. A managed rename takes `SELECT ... FOR UPDATE` on its own company row for the rest of the transaction. It is one row, and no other path in the transaction locks a company row, so there is no lock-order cycle. A self-hosted instance and every non-rename company update never reach the lock. - The one-time repair is best effort. It runs inside a try/catch and logs a warning on failure, so it never blocks authentication. A failed pass is retried on the next request, because its guards still match. - No schema change and no migration. ## Model Used - Provider: Anthropic (Claude) - Model: Claude Opus, model id `claude-opus-5[1m]` - Context window: 1M - Reasoning mode: extended thinking - Capabilities used: agentic tool use through Claude Code (file edits, shell, test runs against an embedded Postgres database) ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:34:42 -07:00
Devin Foley	a4f1b3c533	Move company invites into a tab of the Members page (#12289 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company settings include member management and invites, which are one workflow: invite someone, watch the join request, manage the membership > - Today invites sit on a standalone settings page, costing a sidebar entry and forcing people to bounce between two pages for one task > - Merging invites into the Members page keeps the workflow in one place without losing any capability > - This pull request turns the Members page into a Members/Invites tab bar, redirects the old URL, and keeps both operator-visibility keys meaningful > - The benefit is a tighter settings surface for every deployment, with `company.invites` now hiding just the tab while `company.members` hides the whole page ## Linked Issues or Issue Description No public issue exists; describing the issue inline per the enhancement template: What existing behavior does this improve? Company invites live on a standalone settings page separate from the Members page, even though inviting someone and managing the resulting membership are one workflow. Subsystem affected Web UI (company settings) Current behavior `/company/settings/invites` is its own page with its own sidebar entry (gated by `company.invites`); the Members page (`company.members`) is separate. The sidebar company menu's "Invite people" shortcut links to the invites page and is not gated by the hidden-settings mechanism at all. Proposed behavior The Members page carries a Members/Invites tab bar, addressable via `?tab=invites`. The invite creation flow, latest-link panel, and invite history move unchanged into an `InvitesSection` component. The old URL redirects to the tab (still behind its `HiddenSettingsPageGate`). `company.members` hides the whole page; `company.invites` hides just the Invites tab, and the tab bar collapses when only Members remains. The "Invite people" shortcut points at the tab and hides when either surface is operator-hidden. Reason and benefit One settings surface for one workflow: fewer sidebar entries and no bouncing between two pages to invite someone and then manage the membership. Operators keep the same visibility controls, with a sharper meaning for each key. Breaking changes None. Bookmarks to the old invites URL redirect to the tab, invite and membership APIs are unchanged, and both hidden-settings keys keep working. ## What Changed - `ui/src/pages/CompanyInvites.tsx` → `ui/src/components/access/InvitesSection.tsx` (page chrome and breadcrumbs dropped; content unchanged), with its tests moved alongside. - `ui/src/pages/CompanyAccess.tsx`: Members/Invites tabs via the shared `PageTabBar`, `?tab=invites` search param, `company.invites` gating with tab snap-back; legacy "Open Invites" button retargeted. - `ui/src/App.tsx`: the invites route becomes a gated redirect to `/company/settings/members?tab=invites`. - `CompanySettingsSidebar` / `CompanySettingsNav`: standalone Invites entry/tab removed; the old path maps to the members tab. - `ui/src/components/SidebarCompanyMenu.tsx`: "Invite people" now links to the tab and hides when `company.members` or `company.invites` is hidden (closes an existing gating gap). - Tests: moved invites tests, new tab coverage (default tab, deep link, operator-hidden tab skips the invites fetch), sidebar/nav suites updated. ## Verification - `npx vitest run ui/src/components/CompanySettingsSidebar.test.tsx ui/src/components/access/CompanySettingsNav.test.tsx ui/src/pages/CompanyAccess.test.tsx ui/src/components/access/InvitesSection.test.tsx` — 24 tests passing. - `pnpm --filter @paperclipai/ui typecheck` — clean. ## Risks - Low. Pure UI restructure: invite APIs, membership APIs, and the hidden-settings registry keys are unchanged. Bookmarks to the old invites URL redirect (and stay gated). The `company.invites` key's meaning narrows from "hide the page" to "hide the tab", which is the same effective surface. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:34:32 -07:00
Devin Foley	7551b63ef2	Remove the instance Heartbeats settings page (#12282 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Instance settings collect deployment-wide controls; one of them was the Heartbeats page, an instance-wide list of scheduler heartbeat agents with enable/disable toggles > - The same controls live on each agent's own configuration surface, so the standalone list duplicates them, and its framing no longer matches how heartbeat agents are managed > - Keeping a settings view that no longer makes sense costs every deployment navigation noise and maintenance > - This pull request removes the page, its route, its navigation entries, and its hidden-settings key for all deployments > - The benefit is a smaller, coherent settings surface, with operator hidden-settings lists that still mention the retired key continuing to work unchanged ## Linked Issues or Issue Description No public issue exists; describing the issue inline per the enhancement template: What existing behavior does this improve? The instance settings surface — specifically the Settings → Heartbeats page, which listed scheduler heartbeat agents instance-wide with enable/disable toggles. The view no longer makes sense as a standalone settings page: the same controls are available on each agent's configuration surface, and the instance-wide list framing does not match how heartbeat agents are managed. Subsystem affected Cross-cutting: `ui/` (page, route, navigation), `packages/shared` (settings-visibility registry), docs. Current behavior The page renders at `/company/settings/instance/heartbeats`, appears in the settings sidebar and tab bar, and is hideable by hosting operators via the `instance.heartbeats` key of `PAPERCLIP_HIDDEN_SETTINGS`. Proposed behavior The page, route, and navigation entries are removed for every deployment. The `instance.heartbeats` registry key is retired; operator lists that still send it are logged and ignored, so mixed-version fleets keep working. Remembered settings paths pointing at the old page remap to the settings root. Heartbeat APIs are unchanged. Reason and benefit A smaller, coherent settings surface with no duplicated controls; less navigation noise and maintenance for every deployment. Breaking changes None functional. Bookmarks and remembered paths to the removed page land on the settings root; `PAPERCLIP_HIDDEN_SETTINGS` lists that still include `instance.heartbeats` log a warning and are otherwise honored unchanged. ## What Changed - Deleted `ui/src/pages/InstanceSettings.tsx` (the Heartbeats view) and its route in `ui/src/App.tsx`. - Removed the sidebar entry (`CompanySettingsSidebar`) and tab-bar item (`CompanySettingsNav`). - Removed `"/heartbeats"` from the remembered-settings-path allowlist; remembered heartbeats paths now remap to the settings root. - Retired the `instance.heartbeats` key from the shared settings-visibility registry and the environment-variables doc; documented that retired keys are ignored with a warning. - Dropped the now-unused UI client wrapper for the instance scheduler-agent list (`heartbeatsApi.listInstanceSchedulerAgents`); the server endpoint stays. - Removed the unused `schedulerHeartbeats` query key. ## Verification - `npx vitest run packages/shared/src/settings-visibility.test.ts ui/src/lib/instance-settings.test.ts ui/src/components/CompanySettingsSidebar.test.tsx ui/src/components/access/CompanySettingsNav.test.tsx` — 24 tests passing. - Full `ui` vitest suite: 4426 tests, 4 failures — all in files this PR does not touch; 3 were load-induced timeouts that pass on rerun, and `OnboardingWizard.test.tsx` "renders instead of throwing when the browser denies storage access" fails identically on a clean master checkout (pre-existing). - `pnpm --filter @paperclipai/ui typecheck` and `pnpm --filter @paperclipai/shared typecheck` — clean. - Merged `master` to clear a conflict (see below) and re-ran the four focused suites (24 passing), `ui/src/App.test.tsx` and `ui/src/plugins/bridge.test.ts` (22 passing), and both typechecks — all clean. Full CI is green on the merge commit. ## Merge With master `master` gained the `company` → `organization` copy pass (#12243), which reworded strings inside `ui/src/pages/InstanceSettings.tsx` — the page this branch deletes — producing a modify/delete conflict. Resolved by keeping the deletion: the page is going away, so the rewording of its copy has nothing to apply to. Every other file merged cleanly, and `master`'s rewording in `App.tsx`, `App.test.tsx`, and `CompanySettingsSidebar.tsx` sits away from this branch's structural removals, so both changes survive. The net diff against `master` is unchanged from the pre-merge review: the same 13 files, 23 insertions, 330 deletions. ## Risks - Low. Pure removal of a UI surface; heartbeat data and APIs are untouched. Operators still listing `instance.heartbeats` in `PAPERCLIP_HIDDEN_SETTINGS` get a warning log and otherwise unchanged behavior (covered by the registry's unknown-key handling). Bookmarks and remembered paths to the old page land on the settings root. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [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	2026-08-27 11:31:43 -07:00
Devin Foley	e34ed9801b	Let operators hide the Provider vaults and Proposals tabs (#12284 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Hosting operators (a managed cloud, an internal shared server) tune the settings surface with `PAPERCLIP_HIDDEN_SETTINGS`, which today hides whole pages > - The Secrets page bundles four tabs, and two of them — Provider vaults and Proposals — do not apply to deployments where the operator provisions provider credentials itself > - Hiding the whole Secrets page is too coarse: the Secrets and My secrets tabs stay essential everywhere > - This pull request adds per-tab visibility keys (`company.secrets.vaults`, `company.secrets.proposals`) as a new company-section registry group > - The benefit is that any hosting operator can trim the Secrets page to what fits their deployment, with self-hosted behavior unchanged by default ## Linked Issues or Issue Description No public issue exists; following the enhancement template: What existing behavior does this improve? `PAPERCLIP_HIDDEN_SETTINGS` can hide the whole Secrets page (`company.secrets`) but not individual tabs. Operators of managed deployments need to hide the Provider vaults and Proposals tabs while keeping the rest of the page. Subsystem affected Settings visibility (`packages/shared/src/settings-visibility.ts`) and the Secrets page UI (`ui/src/pages/Secrets.tsx`). Current behavior The Secrets page always renders all four tabs (Secrets, My secrets, Provider vaults, Proposals), polls pending proposals for the badge, and offers "manage vaults" affordances that jump to the vaults tab. Proposed behavior Two new registry keys, `company.secrets.vaults` and `company.secrets.proposals`, hide the corresponding tab: the tab-bar entry disappears, an active hidden tab snaps back to Secrets, the manage-vaults affordances are suppressed, and the pending-proposals poll stops. UI visibility only — the provider-config and proposal APIs stay live for agents and integrations, matching the existing `company.` precedent. Nothing changes when the variable is unset. Reason and benefit* Any hosting operator (a managed cloud, an internal shared server) can trim the Secrets page to what fits their deployment — for example when the operator provisions provider credentials itself, so the vault and proposal flows do not apply — without losing the Secrets and My secrets tabs, which stay essential everywhere. Breaking changes None. With `PAPERCLIP_HIDDEN_SETTINGS` unset (or set to existing keys only) nothing changes; older app versions receiving the new keys ignore them with a warning by design. ## What Changed - `packages/shared/src/settings-visibility.ts`: new `HIDEABLE_COMPANY_SECTIONS` group (`company.secrets.vaults`, `company.secrets.proposals`), `HideableCompanySection` type, `hidesCompanySection()` helper, wired into `HideableSettingKey` / `HIDEABLE_SETTING_KEYS`, re-exported from the package index. - `ui/src/pages/Secrets.tsx`: tab-bar filtering, hidden-tab snap-back effect, gated pending-proposals query, conditional `onManageVaults` on both the import button and dialog (the button's "AWS vault disabled — manage" affordance renders nothing when vaults are hidden), hidden `TabsContent` blocks. - Docs: new bullet in `docs/deploy/environment-variables.md` under "Hiding settings surfaces". - Tests: registry membership/parse cases in `settings-visibility.test.ts`; new render cases in `Secrets.render.test.tsx` (hidden tabs absent + proposals poll skipped; default render keeps both tabs and the poll). ## Verification - `npx vitest run packages/shared/src/settings-visibility.test.ts ui/src/pages/Secrets.render.test.tsx` — 43 tests passing. - `pnpm --filter @paperclipai/shared typecheck` and `pnpm --filter @paperclipai/ui typecheck` — clean. ## Risks - Low. Nothing changes with `PAPERCLIP_HIDDEN_SETTINGS` unset (covered by the default-render test). The keys are UI-visibility only, so agent/integration API access is unaffected. Older app versions receiving the new keys ignore them with a warning by design. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:28:15 -07:00
Devin Foley	325041cb00	fix(assets): accept identity-provider characters in image upload namespaces (#12288 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Humans oversee those agents in teams, so each person has a login and a profile with an avatar > - Avatars, logos and pasted images all go to one asset upload API, which files each object under a namespace > - The avatar namespace embeds the user id, and a deployment can take user ids from an external identity layer, where a subject often holds ":", "\|", "." or "@" > - But the namespace validator accepted only letters, numbers, "/", "_" and "-", so those users got a 400 "Invalid image metadata" error and could not set a profile photo > - This pull request widens the accepted characters, rejects "." and ".." path segments with a clear message, and cleans the namespace in the upload client > - The benefit is that profile photo upload works for every user, and a namespace the API refuses now returns a message that says what is wrong ## Linked Issues or Issue Description No existing issue or open pull request covers this. I searched the issue and pull request lists for "avatar upload", "profile photo", "Invalid image metadata" and "asset namespace" and found no duplicate. The bug report follows. What happened? Profile photo upload fails. `ui/src/pages/ProfileSettings.tsx` sends the namespace `profiles/${user.id}` to `POST /api/companies/:companyId/assets/images`. When the user id comes from an external identity layer it can contain ":", "\|", "." or "@" — for example `oidc:example\|jane.example@example.com`. `createAssetImageMetadataSchema` in `packages/shared/src/validators/asset.ts` accepted only `/^[a-zA-Z0-9\/_-]+$/`, so the route returned 400 "Invalid image metadata" (`server/src/routes/assets.ts`). The image bytes were never the problem, but the message pointed at the image, so the toast gave the user nothing to act on. A second case has the same cause. The agent instructions editor in `ui/src/pages/AgentDetail.tsx` builds a namespace that ends with a filename, such as `agents/<id>/instructions/SKILL.md`. The "." in the filename also failed the check. Expected behavior A profile photo uploads for any user id the app itself issues, and an image pasted into the agent instructions editor uploads for any instruction filename. A namespace the API does refuse returns a message that names the field and states the rule. Steps to reproduce 1. Run Paperclip with an external identity provider, so `user.id` holds an OIDC subject such as `oidc:example\|jane.example@example.com`. 2. Open Settings, then Profile. 3. Choose an avatar image. 4. The upload fails and the page shows "Invalid image metadata". Or, with no identity provider: 1. Open an agent, then the instructions editor, and select a file whose name contains a "." such as `SKILL.md`. 2. Paste an image into the editor. 3. The upload fails with the same error. Paperclip version or commit `master` at `eb86fcd49`. Deployment mode Any deployment whose user ids come from an external identity layer. The instructions-editor case reproduces on a plain self-hosted install too. Agent adapter(s) involved Not adapter-specific (core bug). ## What Changed - `packages/shared/src/validators/asset.ts`: widen the namespace pattern to `/^[a-zA-Z0-9\/_.:@\|-]+$/`, and reject any "/"-separated segment equal to "." or "..". A traversal attempt now gets a clean 400 from the validator instead of an error from the storage provider. - `packages/shared/src/validators/asset.ts`: add `sanitizeAssetNamespace()`, which maps any string to a namespace the schema accepts. It works per segment: it keeps the accepted characters, turns the others into "-", collapses repeated dashes, drops empty and dot-only segments, and caps the result at 120 characters. It returns `undefined` when no segment survives, and the caller then sends no namespace. - `packages/shared/src/validators/asset.ts`: export `ASSET_NAMESPACE_MAX_LENGTH` and `ASSET_NAMESPACE_RULE`, so the rule text and the API error cannot drift apart. - `ui/src/api/assets.ts`: run the namespace through `sanitizeAssetNamespace()` in `uploadImage`. This is one choke point for all callers, so no caller has to know the rule. - `server/src/routes/assets.ts`: name the field in the 400 message — `Invalid image metadata: "namespace" must be 1-120 characters of letters, numbers, or / _ - . : @ \|, and cannot contain "." or ".." path segments`. The zod issue details stay in the response. The UI shows `body.error`, so the toast is now actionable. - Tests: a new `packages/shared/src/validators/asset.test.ts` accept/reject matrix for the schema and the sanitizer; three cases in `server/src/__tests__/assets.test.ts`; one case in `ui/src/pages/ProfileSettings.test.tsx`. ## Verification Targeted runs: ``` npx vitest run packages/shared/src/validators/asset.test.ts # 22 passed npx vitest run server/src/__tests__/assets.test.ts # 11 passed npx vitest run ui/src/pages/ProfileSettings.test.tsx # 2 passed ``` New cases: - Schema: accepts identity-provider ids that hold ":", "\|", "." and "@"; accepts `agents/<id>/instructions/SKILL.md`; rejects `profiles/bad name!`, over-length input, and `.` or `..` segments. - Sanitizer: passes identity-provider ids through unchanged, replaces and collapses the other characters, drops the `.` and `..` segments while keeping a segment of three or more dots, caps at 120 characters without leaving a dot segment behind at the cut, and returns `undefined` when nothing survives. One case asserts the sanitizer output always parses. - Route: 201 for `profiles/oidc:example\|jane.example@example.com`, and the storage service receives that namespace; 400 naming `namespace` for `profiles/bad name!`; 400 for `profiles/../secrets`. - UI: a session user id holding ":" and "\|" uploads, and the namespace reaches the API unchanged. Typecheck: ``` pnpm --filter @paperclipai/shared typecheck # clean pnpm --filter @paperclipai/ui typecheck # clean cd server && npx tsc --noEmit -p tsconfig.json # clean ``` Package suites: ``` npx vitest run --project @paperclipai/shared --exclude "/dist/" # 586 passed, 8 pre-existing failures in src/worktree-seed-source.test.ts npx vitest run --project @paperclipai/ui --exclude "/dist/" # 4402 passed ``` CI runs the server suite as ten shards (five general, five serialized), which is the authoritative full run for this package. All shards pass on this branch. The `worktree-seed-source` failures reproduce on an unmodified checkout of the same base commit and are unrelated to this change. The UI failures seen in that run were 5-second test timeouts caused by running two suites at once on one machine; each file passes when it runs alone. No document states the namespace character rule — I checked `docs/` and `doc/`, where the asset upload endpoint appears only in an OpenAPI registry entry and a smoke-lab note, neither of which describes the metadata fields. The rule now lives in one exported constant that the API error reuses. ## Risks Low risk. - The wider character set does not widen what a caller can write to disk. `server/src/storage/service.ts` already replaces every character outside `[a-zA-Z0-9._-]` in each path segment, and `server/src/storage/local-disk-provider.ts` already rejects "." and ".." segments and any key that resolves outside the base directory. This change moves the "." and ".." refusal earlier, to the validator, so the caller gets a clear 400. - The API is more permissive than before, so no request that used to succeed can start failing. - Namespaces stored before this change keep working. The namespace is not a key that is looked up; it is a prefix under which new objects are filed. - One behavior change worth noting: the UI now cleans a namespace instead of sending it as typed, so a caller that passes an unusable namespace gets a cleaned prefix rather than a failed upload. ## Model Used - Claude (Anthropic), Claude Opus, 1M context window, extended thinking, agentic tool use through Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [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	2026-08-27 11:27:31 -07:00
scotttong	4d82f5eaea	copy: unify user-facing "company" wording to "organization" (#12243 )	2026-08-27 01:04:55 -07:00
Devin Foley	9c03443c48	feat: hideable company settings pages, with import floored on cloud-managed instances (#12199 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The app can run self-hosted or as a cloud-managed instance, where a hosting platform provisions the instance with its company already materialized (the existing `isCloudManagedInstance()` predicate and `cloud_managed` floors) > - The company Import/Export surface lets an operator materialize whole companies from an export bundle; on a cloud-managed instance this bypasses the existing `cloud_managed` company-creation floor and conflicts with platform-owned provisioning > - Importing should be disabled on cloud-managed instances, while export stays open as the data-portability escape hatch > - This pull request floors every import route with 403 `code=cloud_managed` on cloud-managed instances and hides the Import UI there, using the existing predicate and the established floor pattern > - It also extends the operator-hidden settings registry with keys for every top-level company settings page, so a hosting operator can hide any of them with `PAPERCLIP_HIDDEN_SETTINGS` alone next time > - The benefit is one consistent managed-instance policy: cloud-managed instances cannot import companies, self-hosted installs keep the full import surface unchanged ## Linked Issues or Issue Description No public issue exists; the underlying problem follows the enhancement template. What existing behavior does this improve? The company import surface (`/api/companies/import`, `/api/companies/:companyId/imports/`) and its UI entry points on cloud-managed instances. Subsystem affected Server routes (`server/src/routes/companies.ts`) and UI navigation/pages (settings sidebar, settings tabs, org chart, `/company/import` route). Current behavior A cloud-managed instance floors direct company creation (`POST /api/companies` answers 403 `cloud_managed`), but the import routes still accept company bundles, so an import can materialize companies the hosting platform did not provision. The UI offers Import entry points that lead to a surface that is not available on cloud-managed instances. Proposed behavior On instances where `isCloudManagedInstance()` is true, every import route answers 403 `code=cloud_managed` before auth and body work, and the Import UI (sidebar entry, settings tab, org-chart button, `/company/import` route) is hidden or redirected. Export remains fully available. Self-hosted instances are unchanged. Reason and benefit Cloud-managed instances keep one consistent provisioning authority, and users do not see an Import surface that dead-ends in a 403. ## What Changed - `server/src/routes/companies.ts`: a router-level floor mounted at the `/import` and `/:companyId/imports` prefixes. It covers the single-shot upload, preview, job polling, chunked transfer declare/part-upload/status/preview/apply, and the agent-safe per-company import routes. It throws `forbidden(..., { code: "cloud_managed" })` on cloud-managed instances, or `403 settings_operator_managed` when the operator hides `company.import` — both before auth and body validation, mirroring the company-creation floor. - `packages/shared/src/settings-visibility.ts`: new `HIDEABLE_COMPANY_PAGES` registry group — `company.members`, `company.invites`, `company.secrets`, `company.export`, `company.import` — with a `hidesCompanyPage` helper. The company General page stays non-hideable (settings root). `company.import` floors its API; the other keys are UI-visibility only, as documented in the registry, so membership/invite/secret/export APIs stay live for agents. - `ui/src/components/CloudManagedPageGate.tsx` (new): route gate that redirects cloud-managed instances to `/company/settings`, modeled on `HiddenSettingsPageGate`. - `ui/src/App.tsx`: wraps the `company/import` route in `CloudManagedPageGate`. - `ui/src/components/CompanySettingsSidebar.tsx`, `ui/src/components/access/CompanySettingsNav.tsx`, `ui/src/pages/OrgChart.tsx`: hide the Import entry points when `useCloudInstance()` reports a managed instance, and honor the new `company.` hidden-settings keys for every company page entry (sidebar item, tab, org-chart buttons). - `ui/src/App.tsx`: `HiddenSettingsPageGate` route gates for the members (incl. the legacy access route), invites, secrets, export, and import pages under their `company.` keys. - `docs/deploy/environment-variables.md`: documents the new keys and their semantics; the CLI and board-operator guides note that import is unavailable on cloud-managed instances. - Tests: new `server/src/__tests__/company-import-cloud-floor.test.ts` and `ui/src/components/CloudManagedPageGate.test.tsx`, registry cases in `packages/shared/src/settings-visibility.test.ts`, plus cloud and hidden-key cases in the sidebar, settings-nav, and org-chart suites. ## Verification - TypeScript typechecks pass for every workspace package (`tsc` in shared, server, ui; the runner's Rust leg needs a local cargo toolchain and is covered by CI). - `pnpm test` on this branch fails only in 9 files that also fail on a clean `origin/master` checkout on the same machine (environment-dependent suites: live-listener probes, workspace/native-runtime spawns, skill materialization). Zero branch-only failures against that baseline; every suite touched by this change passes. - `server/src/__tests__/company-import-cloud-floor.test.ts` asserts: every import route answers 403 `cloud_managed` under the server-token signal; the managed-config signal alone also floors; every import route answers 403 `settings_operator_managed` when `company.import` is hidden; hiding other company pages leaves import open; the floor applies before auth and body validation; export stays open on cloud-managed instances; self-hosted import preview and job polling still work. - `packages/shared/src/settings-visibility.test.ts` covers the new `company.` keys and `hidesCompanyPage`. - UI suites assert the Import tab, sidebar entry, and org-chart button disappear on a cloud-managed instance while Export stays, that `/company/import` redirects through the gate, and that the `company.` keys hide their sidebar entries and tabs. ## Risks - Low risk for self-hosted installs: the floor is inert unless a cloud signal (`PAPERCLIP_CLOUD_TENANT_SERVER_TOKEN` or `PAPERCLIP_MANAGED_CONFIG`) is present, and the self-hosted paths are regression-tested. - On cloud-managed instances this is a deliberate behavioral removal: import (including agent-driven safe imports and resumable transfers) stops working the moment an instance runs this build. In-flight chunked transfers on such instances cannot be applied afterward; they answer 403. - CLI import commands against a cloud-managed instance now fail with the `cloud_managed` error; the message names the reason. - The new `company.*` keys change nothing unless an operator sets them: `PAPERCLIP_HIDDEN_SETTINGS` unset keeps behavior identical, and older images ignore unknown keys by design. The four non-import company keys hide UI only; their APIs stay live, which the registry documents explicitly. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use (code search, editing, local test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 16:06:35 -07:00
Devin Foley	9fc2f594ae	feat(ui): dashboard banner for paused imported agents with Resume all (#12142 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import parks every imported agent as a safety default > - The only surface that offered to activate them was the post-import checklist, which is UI-only and gone after a reload or an expired import job > - A company whose agents are all paused looks broken: tasks sit still and the dashboard gives no explanation or fix > - This pull request adds a dashboard banner for import-paused agents with a one-click Resume all, and a generic banner when every agent is paused > - The benefit is a durable, reload-proof place to understand and fix the parked state ## Linked Issues or Issue Description What existing behavior does this improve? The company dashboard for a company whose agents are paused, in particular after a company import. Subsystem affected Web UI — dashboard (`ui/src/pages/Dashboard.tsx`). Current behavior Imported agents arrive paused. The activation checklist on the import page is the only activation surface and is lost on reload. The dashboard shows paused counts in a metric card but no explanation and no action. Tasks assigned to the paused agents never start. Proposed behavior When any agent carries the `import` pause reason, the dashboard shows a warning banner ("N imported agents are paused and will not run") with a Resume all action. It resumes each parked agent sequentially, tolerates per-agent failures, and refreshes so the banner reflects whatever remains paused. When no import pauses exist but every agent in the company is paused, a generic all-paused banner links to the agents page. Breaking changes None. Depends on the `import` pause reason introduced in #12140 (this branch is stacked on it). ## What Changed - New exported helper `derivePausedAgentBanner(agents)` deciding between the imported banner, the all-paused banner, or none. - Dashboard renders the banners via the shared `InlineBanner`, with a sequential `agentsApi.resume` mutation for Resume all and query invalidation for the agent list and dashboard stats. ## Verification - `cd ui && npx vitest run src/pages/Dashboard.test.ts` — 4 tests pass (no agents, imported preference, all-paused fallback, mixed-state null). - `cd ui && pnpm run typecheck` — clean. - Manual: import a company package with paused agents, open its dashboard, click Resume all, and watch the banner clear as agents go idle. ## Risks - Low risk. Resume all reuses `POST /agents/:id/resume` with its existing guards, sequentially, matching the import page's activation checklist pattern. At current import sizes (tens of agents) this is fast; a server-side bulk endpoint is the follow-up if imports grow to hundreds of agents. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 14:09:54 -07:00
Dotta	397de98193	feat(runner): add flagged Codex execution adapter (#12188 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The Paperclip Runner now has protocol, provider, tool, package, persistence, and hidden server boundaries. > - The server still cannot select that path for a real agent heartbeat. > - A new runtime must not change any existing direct adapter. > - An experimental runtime must fail closed when its rollout flag is off. > - This pull request adds one guarded Codex vertical slice through runnerd. > - The benefit is a production-built runner path that users cannot start by default. ## Linked Issues or Issue Description Refs #11962 Refs #12111 Refs #12169 Refs #12176 Subsystem affected Cross-cutting. The change affects the runner package, server orchestration, shared settings, and adapter configuration UI. Problem or motivation The hidden PRP coordinator cannot execute a real heartbeat. The application also needs an explicit rollout boundary before it can expose the experimental runner. Existing direct adapters must keep their current execution and finalization behavior. Proposed solution Add `paperclip_runner` as a Codex-only adapter behind the default-off `enableNativeRunner` instance flag. Select the native runtime only for that adapter. Persist the run binding before runnerd starts. Wait for the durable PRP result and terminal event. Resume the real Codex provider thread on later heartbeats. Keep persisted native runs readable and recoverable after the flag changes. Alternatives considered The server could route `codex_local` through runnerd. That option would change an existing adapter and weaken rollback safety. The server could expose all providers now. That option would add unreviewed provider behavior. The build could depend on a prebuilt runner binary. That option would make source builds architecture-dependent and difficult to verify. Roadmap alignment This work supports the shipped enforced-outcomes, governed-tool, and self-healing-run milestones. It does not add a new roadmap surface. It is the guarded execution step after the merged hidden runner boundaries. Additional context This is the next replacement for the closed large runner pull request. Task-thread presentation remains a separate follow-up so this change can preserve the current direct-adapter UI. ## What Changed - Add `paperclip_runner` as an explicit Codex-only adapter. - Add the default-off `enableNativeRunner` instance flag. - Reject fresh create, hire, import, switch, and execution requests while the flag is off. - Allow edits to persisted runner agents while the flag is off. - Recover an already persisted native run even after the flag is disabled. - Keep every built-in direct adapter on its existing runtime path. - Persist an immutable native run binding and revisioned completion contract before runnerd starts. - Execute server to PRP to runnerd to Codex to server through the hidden coordinator. - Validate the durable result against the terminal event and exact completion criteria before finalization. - Preserve the Codex provider thread ID and use `thread/resume` on the next heartbeat. - Strip unsupported Codex configuration fields from the experimental adapter. - Build a target-native release runner binary from source and vendor it into the server distribution. - Install Rust only in the Docker build stage. Do not add a workflow or lockfile change. - Stop the runner process group on completion, cancellation, and forced shutdown. ## Verification - Run `pnpm --filter @paperclipai/paperclip-runner check:all`. All 69 TypeScript tests and 58 Rust tests pass. Protocol, conformance, replay, formatting, and generated-file checks pass. - Run the 12 focused adapter, settings, runtime-selection, coordinator, direct-isolation, and real Codex integration test files. All 186 tests pass. - The real integration test uses PostgreSQL, HTTP, WebSocket, runnerd, and a fake Codex app server. It proves one `thread/start` followed by one `thread/resume`. - Run `pnpm -r typecheck`. - Run `pnpm build`. - Run `pnpm check:token-gates`. - Build the Docker `build` target from a clean context. Confirm that the server distribution contains an executable `paperclip-runnerd` built with Debian Rust 1.85. - Start the server through the source-mode tsx entry point with the package `dist` directory absent. Confirm the vendor shim resolves source exports and the server boots. - Run `pnpm test:run` twice. On this macOS host, 405 files pass and 1 file skips. Eight untouched workspace and loopback tests fail because macOS resolves `/tmp` and `/var` through `/private` and because PID-derived test ports exceed 65535. Linux CI must pass the full suite. - Confirm that the diff contains 52 files. Confirm that it contains no `.github` or `pnpm-lock.yaml` change. ## Risks - The feature flag is off by default. A fresh native start fails with a stable error while the flag is off. - A persisted native run remains recoverable after the flag changes. This prevents rollout changes from corrupting recorded work. - Only local Codex execution is accepted. Other providers and remote work modes fail closed. - Existing direct adapters do not start runnerd, create native rows, use native status arbitration, or enter native finalization. - The runner receives its one-use bootstrap ticket through the child environment. The server does not put the ticket in command arguments or logs. - The server validates the company, task, agent, run, runner, session, completion contract, result, and terminal binding before it accepts completion. - The build compiles a target-native Rust binary. Cross-platform release packaging remains a later concern. Source builds and Docker builds compile for their current target. - Docker needs enough build memory for the existing server TypeScript compile. The Docker build stage sets a 4 GB V8 heap limit. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex with GPT-5. The exact deployment ID and context-window size are not exposed. The model used agentic reasoning, repository tools, code execution, and test execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and applicable tests 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	2026-08-25 16:03:41 -05:00
Devin Foley	fcb84d472d	feat: already-imported transfer error names the landed company (#12144 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Chunked company-import transfers are deduplicated by content: a byte-identical zip that already finished an apply is rejected > - The rejection said only "this exact package was already imported by a completed transfer" without saying where that import went > - Users who could not find the earlier import read the rejection as data loss and kept retrying, or exported again and created duplicate companies > - This pull request makes the declaration response carry the company the completed apply created, and both clients name it in the error > - The benefit is that the dedupe rejection now points at the existing import instead of implying it vanished ## Linked Issues or Issue Description What existing behavior does this improve? The `alreadyCompleted` rejection when re-declaring a chunked company-import transfer. Subsystem affected Shared transfer contract (`packages/shared/src/company-import-transfer.ts`), transfer declaration route (`server/src/routes/companies.ts`), web import page, CLI import command. Current behavior `POST /api/companies/import/transfers` returns `alreadyCompleted: true` with no pointer to the earlier import. Web and CLI raise "This exact package was already imported by a completed transfer. Re-export the package to import it again." Proposed behavior The response includes an optional `company` field (`{id, name, issuePrefix} \| null`) resolved from the completed run's company link. Web and CLI raise a shared message: `… It created the company "Paperclip" (PAPA) — open it from the company switcher. Re-export the package to import it again.` A company that was deleted since (or a link that was never written) degrades to `null` and the original message. Breaking changes None. The new response field is optional; old clients ignore it. ## What Changed - `CompanyImportTransferCreated` gains optional `company`, plus a shared `buildAlreadyImportedMessage` used by both clients. - The declaration route's `alreadyCompleted` branch resolves the landed company null-safely via `companyService.getById`. - Web (`ui/src/pages/CompanyImport.tsx`) and CLI (`cli/src/commands/client/company.ts`) raise the shared message. ## Verification - `cd packages/shared && npx vitest run src/company-import-transfer.test.ts` — 3 tests (named company, id fallback, no-company original message). - `cd server && npx vitest run src/__tests__/company-import-transfer-routes.test.ts` — 24 tests; the re-declaration test now asserts the company payload and the deleted-company null path. - `cd cli && npx vitest run src/__tests__/company-import-transfer.test.ts` — 17 tests; new test pins the named-company message. - `cd ui && npx vitest run src/pages/CompanyImport.test.tsx` — 23 tests. - `pnpm run typecheck` clean in shared, server, ui, cli. ## Risks - Low risk. The lookup runs only on the `alreadyCompleted` branch and is null-safe; the transfer run is already scoped to the requesting actor (user + instance context in the actor key), so the response never names a company the caller did not import. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:50 -07:00
Devin Foley	868e210a95	feat(ui): post-import landing CTAs on every outcome branch (#12143 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import ends on one of two success screens: the full outcome, or a soft-success panel when the job's in-memory result expired before it could be read > - The soft-success panel named no company and offered no way in, and the full outcome never said that paused agents stay resumable after leaving the page > - Users on the soft-success path concluded the import vanished and ran it again, producing duplicate companies > - This pull request gives every success branch a named landing with a direct CTA into the new company and a pointer to the paused-agents banner > - The benefit is that a finished import always lands the user somewhere actionable ## Linked Issues or Issue Description What existing behavior does this improve? The outcome screens of the company import page. Subsystem affected Web UI — company import (`ui/src/pages/CompanyImport.tsx`). Current behavior The expired-job branch renders two sentences ("the company has been added — open it to view it") with no company name and no link. The full-outcome screen shows the activation checklist but does not say the checklist's resume actions remain available on the dashboard, so users treat the page as their only chance. Proposed behavior The expired branch keeps the landed company's name and dashboard path when readable, renders an "Open company dashboard" button, and notes that imported agents arrive paused and can be resumed from the dashboard banner. When the company is unreadable it gives explicit switcher guidance instead. The full-outcome screen states that paused items stay resumable from the dashboard. Breaking changes None. Pure UI copy/state additions to an existing page. ## What Changed - The `expired` import outcome now carries `companyName` and `dashboardPath`, captured from the already-fetched company in `onSuccess`. - The expired panel renders the company name, a dashboard CTA (`data-testid="import-expired-open-company"`), the paused-agents pointer, and a switcher fallback. - The full-outcome screen adds a line noting the dashboard offers the same resume actions as the activation checklist. ## Verification - `cd ui && npx vitest run src/pages/CompanyImport.test.tsx` — 24 tests pass; the soft-success test now asserts the name, pointer, and CTA, and a new test covers the unreadable-company fallback. - `cd ui && pnpm run typecheck` — clean. ## Risks - Low risk. The dashboard pointer references the paused-agents banner shipping in #12142; until that merges the sentence still points at the dashboard, where paused agents are already visible in the metric card. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:46 -07:00
Devin Foley	11f6c754c9	feat: dedicated import pause reason with visible paused-assignee notices (#12140 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import parks every imported agent as a safety default, and issue assignment wakes are dropped for paused agents > - The pause was recorded as the generic reason "system" and was almost invisible: the chat-style task thread showed nothing, the legacy notice had no action, and the new-task dialog gave no hint > - Users assigned tasks in an imported company, nothing ran, and there was no explanation — the imported company looked broken > - This pull request records a dedicated "import" pause reason and makes the paused state visible and fixable where the user is looking > - The benefit is that a silent no-op becomes an explained state with a one-click resume ## Linked Issues or Issue Description What existing behavior does this improve? Working with a company whose agents arrived paused from a company import. Subsystem affected Shared constants (`PAUSE_REASONS`), company import service (`server/src/services/company-portability.ts`), task thread and new-task dialog UI. Current behavior Imported agents get `pauseReason: "system"`, the same value plugin-managed and built-in agent pauses use. Assigning an issue to a paused agent silently drops the wake. The chat-style task thread renders no paused notice; the legacy thread's notice says "It was paused by the system." with no action and only renders when the composer is shown. Proposed behavior Import writes `pauseReason: "import"`. The paused-assignee notice explains the import pause, offers an inline "Resume agent" button (suppressed for budget pauses, which clear on their own), and renders for read-only viewers. The chat-style task thread shows the same notice above the composer. The new-task dialog warns when the selected assignee is paused. Breaking changes None. `PAUSE_REASONS` is widened, not changed; the column already stores free-text values in other paths, and every consumer is an equality check with a manual fallback, so an older client shows the generic fallback copy for the new value. ## What Changed - `packages/shared/src/constants.ts`: `"import"` added to `PAUSE_REASONS`. - `server/src/services/company-portability.ts`: the import pause patch writes `pauseReason: "import"`. - `ui/src/components/IssueChatThread.tsx`: `IssueAssigneePausedNotice` gains import copy, a Resume button, test ids, and is exported; it now renders even when the composer is hidden. New `onResumeAssignee` / `resumeAssigneePending` props. - `ui/src/components/TaskChatThread.tsx`: renders the paused-assignee notice above the composer dock (the chat-style thread previously had no paused surface at all). - `ui/src/pages/IssueDetail.tsx`: wires a resume mutation (`agentsApi.resume`) through both thread variants and invalidates the company agent list. - `ui/src/components/NewIssueDialog.tsx`: inline note when the chosen assignee is paused, with import-specific copy. ## Verification - `cd server && npx vitest run src/__tests__/company-portability.test.ts` — 82 tests pass (pause pin updated to `"import"`). - `cd ui && npx vitest run src/components/IssueChatThread.test.tsx src/components/NewIssueDialog.test.tsx src/components/TaskChatThread.test.tsx` — 120 tests pass (new: notice copy per reason, resume click, budget suppression, active-agent null render, dialog note). - `pnpm run typecheck` in `packages/shared`, `server`, and `ui` — clean. ## Risks - Low risk. The resume action calls the existing `POST /agents/:id/resume` route with its existing guards. Existing rows keep `"system"` and fall back to the current generic copy; only new imports write `"import"`. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:42 -07:00
Devin Foley	d2b9765cc8	feat(ui): offer enabling a skill for agents at install time (#12136 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The company skill library lets operators install skills, and each agent has its own enabled-skill set > - Installing a skill only writes the library row; no agent receives the skill, and the UI says "Skill installed" with no attach step > - Operators install a skill, ask an agent to use it, and the agent truthfully reports the skill as not available — the install felt broken > - This pull request adds an "Enable for agents" step to the install dialog and enables the skill for the selected agents right after install > - The benefit is that "install" defaults to a state where agents can actually use the skill, and the toast is honest when they cannot ## Linked Issues or Issue Description What existing behavior does this improve? Installing a skill from the catalog in the company Skills page. Subsystem affected Web UI — company skills catalog install flow (`ui/src/pages/CompanySkills.tsx`). Current behavior Install writes a `company_skills` row and shows a "Skill installed" toast. No agent is enabled for the skill. Agents resolve their skills from their own desired-skill set, so they report the skill as not installed. The operator has to find the separate "Add to agent" control to make the install effective. Proposed behavior The install dialog shows an "Enable for agents" section for fresh installs. It pre-selects every agent whose adapter supports skills. After install, the page enables the skill for each selected agent (skills sync with mode `add`). The success toast reports how many agents received the skill, and warns when the skill is in the library with no agents enabled. Breaking changes None. Updates and replacements of an existing skill do not show the new section and behave as before. ## What Changed - `InstallPreviewDialog` gains an "Enable for agents" section (fresh installs only) built on the existing `AgentMultiSelect`, with agents whose adapter lacks skills support disabled. - New exported helper `defaultInstallAgentSelection` pre-selects every skills-capable, non-required agent. - The install mutation enables the skill for each selected agent via `agentsApi.syncSkills(..., "add")` before invalidating queries, and reports per-agent failures in a warning toast without failing the install. - Toast copy now distinguishes "enabled for N agents" from "in the library but not enabled for any agent yet". ## Verification - `cd ui && npx vitest run src/pages/CompanySkills.test.tsx` — 23 tests pass, including three new ones: default-selection helper, confirm payload carries the pre-selected agents, update/replace path skips the section. - `cd ui && pnpm run typecheck` — clean. - Manual: install a catalog skill with two agents in the company; both are pre-selected; after install the skill page lists both under "Used by agents". ## Risks - Low risk. Enablement uses the existing per-agent skills sync route with mode `add`, so concurrent edits to an agent's desired set are not overwritten. A per-agent sync failure surfaces as a warning toast and never fails the install itself. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:35 -07:00
dependabot[bot]Priya Raman Paperclip	0b01593602	build(deps): bump lucide-react from 0.577.0 to 1.32.0 (#11885 ) Bumps [lucide-react](https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react) from 0.577.0 to 1.32.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lucide-icons/lucide/releases">lucide-react's releases</a>.</em></p> <blockquote> <h2>Version 1.32.0</h2> <h2>What's Changed</h2> <ul> <li>feat(icons): added <code>car-battery</code> icon by <a href="https://github.com/andreynaz4renko"><code>@andreynaz4renko</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4088">lucide-icons/lucide#4088</a></li> <li>fix(categories): fixes emoji.json by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4697">lucide-icons/lucide#4697</a></li> <li>chore(deps): bump vue from 3.5.40 to 3.5.41 in the vue-deps group across 1 directory by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4695">lucide-icons/lucide#4695</a></li> <li>chore(dev): upgrade ESLint to latest compatible stack (v10) by <a href="https://github.com/ericfennis"><code>@ericfennis</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4378">lucide-icons/lucide#4378</a></li> <li>feat(icons): add square-text by <a href="https://github.com/samuelalake"><code>@samuelalake</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4609">lucide-icons/lucide#4609</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/andreynaz4renko"><code>@andreynaz4renko</code></a> made their first contribution in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4088">lucide-icons/lucide#4088</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/lucide-icons/lucide/compare/1.31.0...1.32.0">https://github.com/lucide-icons/lucide/compare/1.31.0...1.32.0</a></p> <h2>Version 1.31.0</h2> <h2>What's Changed</h2> <ul> <li>feat(icons): added <code>mail-badge</code> icon by <a href="https://github.com/lazerg"><code>@lazerg</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4638">lucide-icons/lucide#4638</a></li> <li>feat(icons): add angle by <a href="https://github.com/samuelalake"><code>@samuelalake</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4545">lucide-icons/lucide#4545</a></li> <li>feat(icons): added <code>eject</code> icon by <a href="https://github.com/ThibautMarechal"><code>@ThibautMarechal</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4043">lucide-icons/lucide#4043</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/lazerg"><code>@lazerg</code></a> made their first contribution in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4638">lucide-icons/lucide#4638</a></li> <li><a href="https://github.com/ThibautMarechal"><code>@ThibautMarechal</code></a> made their first contribution in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4043">lucide-icons/lucide#4043</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/lucide-icons/lucide/compare/1.30.0...1.31.0">https://github.com/lucide-icons/lucide/compare/1.30.0...1.31.0</a></p> <h2>Version 1.30.0</h2> <h2>What's Changed</h2> <ul> <li>chore(icons): refine & rename various emoji icons by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4606">lucide-icons/lucide#4606</a></li> <li>fix(scripts): removed toBeRemovedInVersion from all scripts and tools by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4674">lucide-icons/lucide#4674</a></li> <li>feat(icons): added <code>audio-lines-x</code> icon by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4590">lucide-icons/lucide#4590</a></li> <li>feat(lab): added <code>chinese-character</code> icon to lab by <a href="https://github.com/congemcd"><code>@congemcd</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4212">lucide-icons/lucide#4212</a></li> <li>test(packages): updates unit test snapshots with face-slightly-smiling by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4676">lucide-icons/lucide#4676</a></li> <li>ci(dev): fix post-release job by downloading lucide-font artifact by name by <a href="https://github.com/ericfennis"><code>@ericfennis</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4675">lucide-icons/lucide#4675</a></li> <li>feat(icons): add shield-lock icon by <a href="https://github.com/Caisere"><code>@Caisere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/3508">lucide-icons/lucide#3508</a></li> <li>ci(security): Pin sha actions by <a href="https://github.com/jguddas"><code>@jguddas</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4678">lucide-icons/lucide#4678</a></li> <li>feat(icons): added <code>broom</code> icon by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4683">lucide-icons/lucide#4683</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/congemcd"><code>@congemcd</code></a> made their first contribution in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4212">lucide-icons/lucide#4212</a></li> <li><a href="https://github.com/Caisere"><code>@Caisere</code></a> made their first contribution in <a href="https://redirect.github.com/lucide-icons/lucide/pull/3508">lucide-icons/lucide#3508</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/lucide-icons/lucide/compare/1.29.0...1.30.0">https://github.com/lucide-icons/lucide/compare/1.29.0...1.30.0</a></p> <h2>Version 1.29.0</h2> <h2>What's Changed</h2> <ul> <li>fix(<code>@lucide/lab</code>): Fix lab build by <a href="https://github.com/ericfennis"><code>@ericfennis</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4618">lucide-icons/lucide#4618</a></li> <li>feat(copilot): remove incorrect spaces clause from copilot instructions by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4623">lucide-icons/lucide#4623</a></li> <li>feat(docs): remove Super and Noodle from showcase by <a href="https://github.com/karsa-mistmere"><code>@karsa-mistmere</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4626">lucide-icons/lucide#4626</a></li> <li>chore(deps-dev): bump <code>@angular/platform-server</code> from 21.2.18 to 21.2.19 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4629">lucide-icons/lucide#4629</a></li> <li>ci(security): improve security with adding permissions by <a href="https://github.com/ericfennis"><code>@ericfennis</code></a> in <a href="https://redirect.github.com/lucide-icons/lucide/pull/4619">lucide-icons/lucide#4619</a></li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lucide-icons/lucide/commit/75b55160aa9edd7095dfed1a6e3d88e66fb2b153"><code>75b5516</code></a> chore(dev): upgrade ESLint to latest compatible stack (v10) (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4378">#4378</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/0f8d48b266e7af1e2bab49ff12ab6ec0795ed204"><code>0f8d48b</code></a> test(packages): updates unit test snapshots with face-slightly-smiling (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4676">#4676</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/f229f83f0c42f46befeac3cfd8ef7aaa82a71325"><code>f229f83</code></a> chore(depedencies): Update dependencies (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4553">#4553</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/5ff536e1391335e4f7dc38d244c1bc458b9443e2"><code>5ff536e</code></a> ci(release.yml): Fix workflow and remove <code>version</code> scripts in package scripts...</li> <li><a href="https://github.com/lucide-icons/lucide/commit/07c885e6c1f9952965ba388b7fd2bb7c4d416a67"><code>07c885e</code></a> fix(docs): fix zephyr-cloud URL in readmes</li> <li><a href="https://github.com/lucide-icons/lucide/commit/50d8af5a1012e188f3d71ac8f1fc0fba1aab5357"><code>50d8af5</code></a> docs(readme): Update readme files (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4320">#4320</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/653e44b83293567ff24dcb90ca1094a9cf0a042a"><code>653e44b</code></a> feat(packages): use .mjs for ESM bundles (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4285">#4285</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/7623e23f787fe78e5075a613fd22da2cecbb9b1b"><code>7623e23</code></a> feat(docs): add Zephyr Cloud to Hero Backers tier & rework updateSponsors scr...</li> <li><a href="https://github.com/lucide-icons/lucide/commit/dada0a82970d3733d1d716e2089591c538272a39"><code>dada0a8</code></a> fix(lucide-react): Fix dynamic imports (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4210">#4210</a>)</li> <li><a href="https://github.com/lucide-icons/lucide/commit/a6e648a66ff470c2255d3666765fd73cfcc185ff"><code>a6e648a</code></a> fix(lucide-react): correct client directives in RSC files (<a href="https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react/issues/4189">#4189</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lucide-icons/lucide/commits/1.32.0/packages/lucide-react">compare view</a></li> </ul> </details> <br /> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Priya Raman <priya@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-25 10:54:14 -07:00
TonioandClaude Opus 5	88a0f885e8	Brand lockup, no idle env-check card, no Mission row (#12074 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - New customers meet the product through an onboarding arc that ends in the tenant wizard > - A staging walk of that arc found three rough edges: an ad-hoc icon standing in for the brand, an environment-check card that narrates a probe the flow already runs on its own, and a review checklist that still lists a Mission the arc stopped asking for > - Each one makes the product look less finished than it is at the exact moment a customer decides what it is > - This pull request renders the brand lockup, hides the idle environment-check card while keeping the probe and its failure surface, and drops the Mission row > - The benefit is a first-session arc that reads as one product, with no controls for questions nobody was asked ## Linked Issues or Issue Description No public issue exists. The changes come from walking the sign-up arc on a staging fleet. What happened: The model step shows an "Adapter environment check" card with a "Test now" button even though pressing Connect runs the same probe and blocks a failing hire. The review step lists "Mission" in its checklist although onboarding no longer asks for one. The auth page renders a sparkles icon beside the word "Paperclip" instead of the brand lockup. Expected behavior: The model step shows the check only when a probe has found something to fix. The review checklist lists only what onboarding set up. The brand renders as the lockup asset used across surfaces. Actual behavior: An idle card narrates a probe that runs regardless. A permanent unchecked row marks a question nobody was asked. The brand is a generic icon plus text. Steps to reproduce: 1. Sign up on a staging fleet and enter the tenant wizard. 2. On "Create your first agent", choose a role and press Next: the model step shows the "Adapter environment check" card before anything has been probed. 3. Continue to Review: the checklist lists "Mission" as a permanently unchecked row. Additional context: The Mission row outlived the removal of the mission step (#11935). The environment probe itself still runs on Connect and blocks a failing hire; only its idle card is at issue. The brand lockup lands across all three surfaces in the same round — paperclip-cloud#270 and paperclip-id#58 carry the other halves. ## What Changed - `PaperclipLockup` renders the brand asset (mark + wordmark, one geometry, `fill="currentColor"`); the auth page uses it in place of the sparkles icon. - The adapter environment check's idle card (explainer + "Test now") no longer renders. The probe still runs on Connect and still blocks a failing hire. - The check's failure content still renders when a probe has found something — the blocking error points the customer at "the reported checks", so they stay visible. - Connect retries a cached failed probe instead of reusing it. With "Test now" gone, Connect is the only retry, and a stale fail would lock out a machine the customer has since fixed. - The review checklist drops its "Mission" row. ## Verification Run the tenant suite: ``` cd ui && npx vitest run ``` - 4365 tests pass across 471 files; `npx tsc --noEmit` is clean. - New test drives the wizard to the model step and asserts the environment-check card is absent, anchored on "Connect a model" so an unrendered step cannot pass as an absence. - The review assertions anchor on the remaining rows ("Organization name", "Agent created", "Model connected"). ## Risks - Behavioral change: a cached failed probe is re-run on Connect instead of reused. Pass and warn results are still cached. This only affects the retry path that "Test now" used to serve. - Hidden, not removed: the environment check machinery is intact; only the idle card is gone. A failing probe still blocks the hire and still shows its checks. - Brand: the wordmark now ships inside an SVG; its accessible name carries the text. Screen readers announce "Paperclip" as before. ## Model Used Claude Fable 5 (`claude-fable-5`) via Claude Code, with tool use and code execution; earlier rounds on this branch's predecessor used Claude Opus 5 (`claude-opus-5`). ## 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 - [x] My branch name describes the change and contains no internal Paperclip ticket id - [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 merge --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 01:35:15 -07:00
Devin Foley	c62bb4b16b	feat: environment delete with agent reassignment and consented sandbox destroy (#12053 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Environments define where agent runs execute: local, SSH, or provider sandboxes > - Operators can create and edit environments, but the UI has no way to delete one > - The server already exposes `DELETE /environments/:id` and a delete-blast-radius preflight, but no UI consumes them, and a delete blocked by reusable sandbox leases gives the operator no path forward > - This pull request adds the delete flow to the environment configuration page: a preflight-driven modal that reassigns dependent agents, names the workspaces that hold blocking sandbox leases, and can destroy those sandboxes with explicit consent > - The benefit is that operators can retire stale environments from the UI without database surgery, and dependent agents move to a chosen replacement instead of silently falling back ## Linked Issues or Issue Description Refs #8554 Refs #11124 Subsystem affected Environments (server routes, environment runtime service, and the environment settings UI). Problem or motivation The environment configuration page has no delete control. The server delete endpoint exists, but nothing in the UI calls it. When reusable sandbox leases block a delete, the 409 error names no owner, so the operator cannot find the blocking workspace. Agents that use the environment as their default lose it silently through the FK `on delete set null`. Proposed solution Add a delete button with a confirmation modal on the environment edit page. The modal reads the delete-blast-radius preflight. It offers a dropdown to reassign dependent agents to another environment before the delete. It lists each workspace that holds a blocking reusable sandbox lease, with a link. When those leases are the only blocker, the confirm button destroys the sandboxes inline (`?destroyReusableSandboxLeases=true`) and then deletes. A failed teardown falls back to `pending_cleanup` for the sweep, so no sandbox is orphaned. ## What Changed - `ui/src/pages/CompanyEnvironments.tsx`: delete button on the edit page header, confirmation modal with agent reassignment select, lease-holder list, impact notes, and a consent-labeled destroy-and-delete action - `ui/src/api/environments.ts`: `deleteBlastRadius` and `remove` client methods; `remove` takes an optional `destroyReusableSandboxLeases` flag - `server/src/routes/environments.ts`: `DELETE /environments/:id` accepts `?destroyReusableSandboxLeases=true`; it destroys the environment's reusable sandbox leases first, but only when those leases are the sole delete blocker, then re-checks the blast radius before it deletes - `server/src/services/environment-runtime.ts`: new `destroyReusableSandboxLeasesForEnvironment` — destroys every reusable sandbox lease an environment still owns while the environment config (provider credentials) is still available - `server/src/services/environments.ts`: the delete blast radius now returns `reusableSandboxLeaseHolders` (lease id, workspace, issue) so clients can name what blocks a delete - `packages/shared/src/types/environment.ts`: `EnvironmentDeleteReusableLeaseHolder` type on the blast radius - Tests: route gating for the consent flag (destroy runs, mixed-blocker rejection, surviving-lease rejection), runtime destroy scoped to an environment, blast-radius holder join, and UI tests for the reassignment flow, holder links, and the consent button ## Verification - `npx vitest run server/src/__tests__/environment-routes.test.ts server/src/__tests__/environment-service.test.ts server/src/__tests__/environment-runtime.test.ts ui/src/pages/CompanyEnvironments.test.tsx` - Manual: open Settings → Environments → edit an environment. The trash icon opens the modal. With agents on the environment, pick a reassignment target and confirm; agents move and the environment deletes. With reusable sandbox leases, the modal names the holding workspaces and the confirm button reads "Destroy N sandboxes and delete". ## Risks - The consented path destroys provider sandboxes. It runs only when reusable leases are the sole blocker, so a delete that would still be rejected never destroys anything. A failed teardown routes to `pending_cleanup` and the delete stays blocked until the sweep resolves it. - Agent reassignment issues one PATCH per agent from the client. A mid-sequence failure leaves some agents reassigned; the reassignments are valid on their own and the UI refreshes to the actual state. - Hard blockers (managed local, instance default, pending cleanup) keep the existing 409 behavior and disable the confirm button. ## Model Used - Claude (Anthropic) — Fable 5, model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code CLI. ## 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 merge	2026-08-23 16:53:17 -07:00
Nicky LeachandPaperclip	63df7ad2b3	feat(login): use the login pseudo-terminal for Codex device login and de-Claude the shared channel (#12020 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agent adapters use provider-specific login flows > - Codex device login needs a live pseudo-terminal (PTY), while the shared channel still uses Claude-specific names > - The old streamed-exec path does not provide the prompt transport that Codex needs > - This pull request moves Codex device login to the shared login PTY and removes the dead streamed-exec path > - The benefit is one controlled login transport with fail-closed capability checks and safer credential reads ## Linked Issues or Issue Description Problem or motivation Codex device login used a streamed-exec path that did not provide the required prompt transport. The shared login channel also exposed Claude-specific names outside Claude code. Expected behavior The host selects a fixed login command from trusted adapter data. Codex login uses the provider login PTY. Providers without that capability fail closed. Proposed solution Use a server-controlled session home, create and validate it as a fresh 0700 directory, read credentials from one validated descriptor, and rename shared channel names to the neutral login PTY family. Alternatives considered Keep the shared login PTY as the single transport. Do not keep the removed streamed-exec path because it cannot provide the required prompt transport. Roadmap alignment This change supports the planned login transport work. It does not add a separate roadmap item. ## What Changed - Route Codex device login through the shared login PTY transport. - Select the login command from a closed internal command key. - Carry a server-controlled session home through the launch contract. - Create and validate the session home as a fresh 0700 directory owned by the login user. - Read the credential file with descriptor-relative, no-follow path walking and final descriptor checks. - Gate the login route and run lease on the provider login PTY capability. - Rename shared channel names to the neutral login PTY family. - Remove the streamed-exec transport value, selector field, driver branch, and related tests. - Hide Codex login in the user interface when the provider lacks the login PTY capability. ## Verification - Server unit suites pass: 89/89. - Adapter-utils suites pass: 262/262. - Codex-local suites pass: 326/326. - Credential-read reader suite passes: 20/20. - Daytona login PTY suite passes: 30/30. - Device-login suites pass: 56/56. - TypeScript checks pass for server, adapter-utils, and UI. - GitHub Actions must pass after pull request creation. - Greptile review must reach 5/5 with no open P2 findings, recommendations, or follow-ups. ## Risks - Providers without a login PTY capability lose Codex login support by design. - The credential read rejects invalid ownership, mode, type, path, and size. - The launch-time sandbox directory race remains outside the threat model because the login runs inside the sandbox and a hostile sandbox already controls its credential. ## Model Used OpenAI Codex, GPT-5, tool use and code review assistance. The exact context window and reasoning mode are 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>	2026-08-23 09:44:59 -07:00
DottaandPaperclip	f572e08678	fix(recovery): stop automatic stranded-task takeovers (#11961 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The recovery service restores execution when a task loses its live path. > - The service retries the original agent for a limited number of attempts. > - The old fallback could select a manager or an executive and wake that agent. > - That fallback changed the effective recovery owner without a board decision. > - This pull request keeps the source owner and gives the exhausted recovery decision to the board. > - The benefit is a clear ownership rule with no automatic task takeover. ## Linked Issues or Issue Description Refs: #11807 Refs: #11817 What existing behavior does this improve? This improves stranded-task recovery in the server and the recovery action card in the board UI. Subsystem affected Cross-cutting: server recovery orchestration, recovery observability, board UI, and execution documentation. Current behavior Paperclip retries the original agent for a limited number of attempts. After the retry limit, it can select a manager, task creator, CTO, or CEO as a recovery owner. It can then wake that substitute agent. The source task keeps its assignee, but the automatic substitute wake creates an implicit takeover path. Proposed behavior Paperclip keeps the limited retry path for the original agent. If recovery is exhausted or unsafe, Paperclip creates one board-owned source recovery action. It keeps both source assignee fields. It does not wake a substitute agent. The board can repair, retry the original owner, explicitly reassign, or resolve the task. Reason and benefit Source task ownership must remain stable until a person or an approved policy changes it. The new rule removes implicit manager and executive takeover. It also gives operators clear evidence through the `board_escalation_no_takeover_v1` routing marker. Breaking changes Automatic recovery no longer wakes a manager or executive after the original-agent retry limit. Existing active agent-owned recovery actions remain visible and can resolve. Paperclip does not schedule a new takeover wake for those legacy actions. ## What Changed - Route exhausted and unsafe stranded recovery to a board-owned source action. - Preserve agent and user assignee fields during automatic escalation. - Keep limited same-agent continuity repair and provider quota monitoring. - Stop new manager, creator, CTO, and CEO recovery wakes. - Keep legacy agent-owned recovery actions readable and resolvable. - Add the routing marker to new board escalation evidence and observability. - Update recovery notices, the board UI card, tests, and execution documentation. ## Verification - Run `pnpm -r typecheck`. - Run `pnpm build`. - Run `pnpm check:token-gates`. - Run `pnpm --filter @paperclipai/server exec vitest run src/__tests__/heartbeat-process-recovery.test.ts`. - Run `pnpm --filter @paperclipai/server exec vitest run src/__tests__/heartbeat-workspace-branch-containment.test.ts`. - Run the focused recovery and UI Vitest files changed by this pull request. - Confirm that a paused or over-budget source owner creates one board action, keeps the source assignee, and creates no substitute wake. ## Risks - Operators must now make the final recovery decision after the original-agent limit. - Legacy agent-owned actions use their stored contract. This avoids a rollout-time ownership rewrite. - No database migration or API response shape changes are included. - The tests cover concurrent escalation, paused and over-budget owners, legacy actions, provider quota monitoring, and UI presentation. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI Codex with GPT-5. The hosted exact model revision and context window are not exposed. Reasoning, tool use, and code execution were 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>	2026-08-22 11:41:24 -05:00
Nicky LeachandPaperclip	10d2781a29	feat(sandbox): add the duplex bridge broker, gated transport selection, and fixed observability (#11769 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Sandbox adapters provide controlled execution for untrusted provider environments. > - The sandbox channel needs one persistent duplex transport with strict host control. > - The transport must remain off unless the instance setting and provider capability both allow it. > - The host must detect loss, bound resource use, and expose only safe telemetry. > - This pull request adds the broker, gated selection, kill-switch wiring, fixed observability, and real-process proof. > - The benefit is safer sandbox execution with bounded failure behavior and inspectable transport results. ## Linked Issues or Issue Description No public issue exists for this change. The related pull requests are #11738 and #11750. Problem or motivation The sandbox duplex channel needs a host-controlled broker, strict transport gates, bounded provider input, and safe loss telemetry. Without these controls, a provider can cause replay, resource growth, unsafe endpoint selection, or data exposure through telemetry. Proposed solution Add a host broker with nested time limits, request limits, one-shot loss, and per-id deduplication. Select duplex transport only when the instance setting and provider capability both equal true. Assign the endpoint and nonce on the host. Reject invalid readiness data and use the file bridge on failure. Add fixed redacted telemetry and a real-process end-to-end test harness. Alternatives considered Keep the file bridge as the only transport. This avoids new channel behavior but does not provide persistent duplex operation for supported sandbox providers. Roadmap alignment This change supports the Cloud / Sandbox agents section in ROADMAP.md. ## What Changed - Add the duplex bridge broker with bounded forward, response, and gateway wait budgets. - Bound concurrent requests, lifetime requests, and request-id bytes before retention or forwarding. - Select duplex transport only when both required gates are true. - Assign the loopback port and nonce on the host and enforce a liveness-only READY frame. - Fall back to the file bridge after invalid readiness, contamination, bind failure, or timeout. - Carry the kill switch through the server, acpx engine, and six local adapters. - Add fixed, redacted duplex telemetry with a provider allowlist. - Add a real-process end-to-end harness for readiness, round trips, loss, and teardown. - Add regression coverage for limits, loss, UTF-8 splits, concurrency, and telemetry dimensions. ## Verification - Adapter-utils, server, and Daytona typechecks pass locally. - Adapter-utils tests pass, including the codec, broker, execution-target sandbox, and real-process harness. - Server kill-switch tests pass. - Live Daytona tests pass with the required provider key and skip without that key. - The root pnpm-lock.yaml file has no diff. - The branch contains ten commits after origin/master. ## Risks - Duplex transport remains disabled unless both gates equal true. - A provider remains an untrusted boundary and needs least-privilege credentials and quotas. - The server telemetry recorder stays deferred; the default recorder does nothing. - A provider that pre-binds the host port causes a fail-closed fallback to the file bridge. - The change adds no database migration and changes no root lockfile. ## Model Used OpenAI GPT-5, exact model family GPT-5, large context window, reasoning, and tool use. The model assisted with Git handoff validation and PR preparation. The implementation commits came from the engineering worktree. ## 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/... or 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 - [x] I searched the GitHub PR list for similar PRs and confirmed this is not a duplicate --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-22 09:01:31 -07:00
TonioandClaude Opus 5	3ff636bc48	Drop the mission step from the wizard arc (#11935 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - New customers arrive through an onboarding arc that spans Paperclip Cloud and the tenant app > - Cloud's naming screen stopped asking for the company mission, but the tenant wizard still decided its first step by asking whether the company had one > - Every Cloud-created company therefore looked mission-less on arrival, so every walk detoured through a "Define your mission" screen the design had already removed > - This pull request removes that step from the arc, and makes step 1 create the company itself > - The benefit is a shorter arc that matches the design, and a three-step progress strip that now counts the steps that exist ## Linked Issues or Issue Description No public issue exists. The problem was found by walking staging end to end. What happened: A new customer signs in, names their organization, and waits for it to build. The tenant wizard then asks "Define your mission" before it asks for the first agent. Cloud no longer collects a mission, so this screen appears for every new customer. Expected behavior: The wizard asks for the first agent, the model, and a review. The progress strip counts three steps. Actual behavior: The wizard asks for the mission first. The progress strip counts five segments, because the run does not enter on the agent arc. Additional context: Three merged pull requests built the mission-based step choice this change removes: #11352, #11416 and #11429. The mission is now collected later, inside the tenant app, so onboarding does not ask for it at all. ## What Changed - `onboardingStepForCompany` always returns the agent step. The `companyHasMission` parameter is removed, because it cannot change the answer. - `resolveRouteOnboardingOptions` no longer accepts `companyHasMission`. - The dashboard no longer waits for the goal lookup before it opens the wizard. That wait only chose a step, and the step is now fixed. - Step 1 creates the company in a new `handleCreateCompany`. Company creation used to sit at the end of `handleConfirmMission`. - No company goal is written during onboarding. - The three-step strip now shows on the agent, model and review steps, because every Cloud-first run enters on the arc. - The full-length bar drops its second segment. No run can fill it. - The grow path keeps its step 2 questionnaire. Only the create path skips ahead. - Back from the agent step goes to the screen the run came from. - Four end-to-end specs no longer drive the wizard through the mission step. ## Verification Run the tenant test suite: ``` cd ui && npx vitest run ``` - 4356 tests pass. 471 files pass. - `npx tsc --noEmit` reports no errors. - Fault injection: forcing `skipsMissionStep` to `true` fails the grow questionnaire test. Removing the Back rule fails the Back test. Both tests fail on the exact defect they guard. - The three-step strip is asserted by an existing test. It checks `Step 1 of 3` and `aria-label="Create your first agent"`. Manual check on staging after the paired Cloud change: 1. Open a new incognito window. 2. Sign in with a new account. 3. Name the organization. 4. Confirm the wizard shows "Create your first agent" and "Step 1 of 3". ## Risks - Behavioral change. Onboarding no longer writes a company goal. An agent hired during onboarding starts without a seeded mission. This is intended. The mission moves to the tenant app. - Dead code. `ONBOARDING_MISSION_STEP` and the mission screen stay in the codebase, but nothing in the app opens them. They wait for the surface that collects the mission later. - Grow path. The grow path is unchanged, but it shares step 2 with the removed screen. New tests cover it. - Superseded work. #11352, #11416 and #11429 tuned the mission-based step choice. This change removes the branch they tuned. ## Model Used Claude Opus 5 (`claude-opus-5`), extended thinking, with tool use and code execution through Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links - [x] My branch name describes the change and contains no internal Paperclip ticket id - [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 merge --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 02:28:45 -07:00
Devin Foley	adfbe2d4b9	feat(environments): refer to the managed default environment by name, not the sandbox driver key (#11838 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Managed deployments provision a platform-managed default environment for agent runs; the UI shows this environment in selectors, the agent form, run details, and the environments page > - Those surfaces append the raw driver key to the environment name, so users see labels like "Paperclip Computer (sandbox)", "Paperclip Computer · sandbox", and fallback copy such as "Managed sandbox" and "The sandbox has no ready authentication" > - "sandbox" is infrastructure vocabulary, not the product name of the environment; showing it next to the managed environment's name is confusing and off-brand > - This pull request renders platform-managed environments by name alone and rewords the sandbox-phrased copy, while user-created environments keep the driver suffix so mixed lists stay distinguishable > - The benefit is that the default environment reads as one clear product name everywhere, and self-hosted users lose nothing: their own environments still show the driver ## Linked Issues or Issue Description What existing behavior does this improve? Display of the platform-managed default environment across the UI. Subsystem affected UI (environment selectors, agent config form, environments page, agents page, run details) and the claude-local/codex-local adapter auth checks. Current behavior The agent form labels the inherited default environment as "Name (sandbox)". Environment selectors and the environments list render "Name · sandbox". The agents page describes the environment as "<provider> sandbox provider". The agent form's fallback label is "Managed sandbox". Adapter auth checks say "The sandbox has no ready authentication for this adapter." Proposed behavior Platform-managed environment rows (`metadata.managedByPaperclip`) render their name alone. The fallback label is "Paperclip Computer". The agents page describes managed environments as "Managed by Paperclip". Run details omit the driver suffix for sandbox-driver environments (the adjacent Provider entry already identifies the mechanism). Adapter auth checks say "This environment has no ready authentication for this adapter." Reason and benefit The managed environment carries a product name. Appending the raw driver key ("sandbox") to it is noise and contradicts the product naming. User-created environments keep the driver suffix, so mixed lists stay distinguishable. Breaking changes None. Message text of the auth check is not read programmatically; the UI keys off `ADAPTER_AUTH_MISSING_CHECK_CODE`. Rows without the managed marker render exactly as before. ## What Changed - New `environmentDisplayLabel` helper in `ui/src/lib/managed-sandbox-environment.ts`: managed rows → name alone; other rows → "Name · driver". - `AgentConfigForm`: inherited-default label uses the helper; fallback copy "Managed sandbox" → "Paperclip Computer"; environment options use the helper. - `ProjectProperties`, `CompanyEnvironments`: environment selector options use the helper; the environments-list row hides the driver suffix on managed rows; the managed detail page's fallback description no longer says "sandbox". - `Agents` page: managed environments are described as "Managed by Paperclip" instead of "<provider> sandbox provider". - `CommentThread` run details: the driver suffix is omitted for sandbox-driver environments. - claude-local and codex-local adapters: auth-missing check message/hint reworded from "sandbox" to "environment" (ACP and environment-test paths); claude-local probe/effort/login hints reworded the same way. - Run status lines: "Syncing workspace to sandbox", "Exporting git changes from sandbox", "Starting adapter in sandbox", and friends now say "environment"; "Finalizing sandbox workspace" → "Finalizing workspace". Templated transfer-progress lines map the `sandbox` transport key to "environment" for display (`runtime-progress.ts`). - Agent form sign-in panel: "Sign in to the sandbox" → "Sign in to the environment"; "Authenticated. The sandbox has credentials now." → "…The environment has credentials now." - Feature catalog + instance settings card: "Managed Sandbox Only" → "Managed Environment Only" (setting key unchanged; the card keeps its alphabetical slot). - Server agents routes: execution-target failure and test-identity copy no longer say "sandbox"; workspace-mode label "Cloud sandbox" → "Cloud environment". - Tests: new `environmentDisplayLabel` unit cases; new `AgentConfigForm` render case asserting the managed default renders without "(sandbox)" or "· sandbox"; status-line assertions updated across adapter-utils, server heartbeat/live-run, and UI chat suites. ## Verification - `pnpm --filter @paperclipai/ui typecheck` — clean. - `pnpm --filter @paperclipai/adapter-claude-local typecheck` and `--filter @paperclipai/adapter-codex-local typecheck` — clean. - `vitest run` for `managed-sandbox-environment.test.ts`, `AgentConfigForm.render.test.tsx`, `CompanyEnvironments.test.tsx`, `Agents.test.tsx`, `CommentThread.test.tsx`, `NewAgent.test.tsx` — all green (118 tests across the two runs). ## Risks Low risk. Cosmetic label changes only; no data or API changes. Rows without `metadata.managedByPaperclip` render exactly as before, so self-hosted deployments with their own environments see no change. The only self-hosted-visible wording changes are the adapter auth-check message and the driver suffix omission on sandbox-driver rows in run details. ## Model Used - Claude (Anthropic) — claude-fable-5 (Claude Fable 5), Claude Code CLI, extended thinking, tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no docs reference these labels) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-21 12:51:22 -07:00
Michael NguyenandClaude Fable 5	773a9dade6	fix: preserve plugin detail-tab deep links and bridge the real JSX runtime (#11826 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Plugins can contribute detail tabs to project pages, and plugin UI bundles render through a host-provided React bridge > - A cold load of a plugin-tab deep link redirected to the Issues tab, because the plugin-slots query is disabled until the project's company resolves and a disabled query reports `isLoading: false` > - The redirect made shareable plugin-tab URLs and browser reload/back/forward unreliable for every detail-tab plugin > - Separately, the bridge shim rebuilt `jsx`/`jsxs` on top of `createElement(type, { children })`, which drops React's static-children marking and floods the dev console with "unique key" warnings from plugin components > - This pull request holds the tab decision on a skeleton until contributions actually load, and exposes the host's real `react/jsx-runtime` on the plugin bridge with the old shim as fallback > - The benefit is that plugin detail tabs survive direct open, reload, back, and forward, and plugin surfaces stop emitting spurious React key warnings ## Linked Issues or Issue Description What happened Opening a project URL with `?tab=plugin:<publisher>.<plugin>:<tab>` directly, or reloading while on such a tab, redirected to the project's Issues tab even though the plugin contribution was registered and available. The dev console also showed "each child in a list should have a unique key" warnings pointing at plugin-rendered components. Expected behavior Direct open, reload, back, and forward keep the requested plugin tab when its contribution is available. When the contribution truly does not exist, the page still falls back safely to the Issues tab. Plugin components with static multi-child JSX render without React key warnings. Steps to reproduce 1. Install a plugin that contributes a project detail tab. 2. Open the tab, copy the URL, and open it in a new browser tab (or press reload). 3. Observe the redirect to `/projects/<ref>/issues` before the plugin-slots query has ever run. 4. With React in development mode, open any plugin tab that renders sibling elements and observe key warnings in the console. Version or commit Reproduced on `master` at `733ffbf7c`. Deployment mode Local development instance (managed runtime). ## What Changed - `ui/src/pages/ProjectDetail.tsx`: the plugin-tab fallback now waits until the company is resolved and the plugin-slots query has finished before it decides. While the decision is pending it renders the detail `PageSkeleton` instead of navigating away. Loading a project that fails to load still shows the error state. - `ui/src/plugins/bridge-init.ts`: the plugin bridge registry now exposes the host's real `react/jsx-runtime` module as `reactJsxRuntime`. - `ui/src/plugins/slots.tsx`: the `react/jsx-runtime` shim served to plugin bundles prefers the bridged runtime's `jsx`/`jsxs`/`Fragment` and keeps the previous `createElement`-based implementation as a fallback. - `ui/src/pages/ProjectDetail.test.tsx`: new tests for cold deep links — pending slots query, disabled query before company resolution, registered tab render, and fallback when the tab is not contributed. - `ui/src/plugins/bridge.test.ts`: new tests that the bridge exposes the real runtime and that unkeyed static children render through it without key warnings. ## Verification - `npx vitest run src/pages/ProjectDetail.test.tsx src/plugins/bridge.test.ts` in `ui/` — 2 files, 18 tests, all pass. - `pnpm check:token-gates` — all gates clean. - Manual: open a project with a plugin detail tab, switch to the tab, reload the browser, use back/forward, and open the URL in a fresh tab. The tab persists. Remove the plugin and open the same URL. The page falls back to the Issues tab. ## Risks - Low risk. The fallback redirect still happens whenever contributions finish loading without the requested tab; the change only defers it until the answer is known, so an unavailable contribution cannot get stuck on the skeleton. - The jsx-runtime shim keeps the old `createElement` path as a fallback when the bridged runtime is absent, so older bridge registries keep working. ## Model Used - Claude (Anthropic) — `claude-fable-5`, extended thinking enabled, agentic tool use (file edits, shell, test execution) via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or similar PRs and linked related PRs above where they exist - [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) - [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details — the branch predates this rule; squash-merge keeps the branch name off `master` - [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 (code-level docs; no user-facing docs affected) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green — pending first CI run on this PR - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups — pending first review - [x] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-08-20 23:22:49 -07:00
Devin Foley	db4defdfbf	feat: operator-configurable settings visibility via PAPERCLIP_HIDDEN_SETTINGS (#11823 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The instance settings surface (Access, Plugins, Adapters, General, Experimental) assumes the person at the keyboard operates the whole instance > - Operators who host Paperclip for others — a managed cloud or an internal shared server — expose settings pages and toggles that do not apply to their deployment, and the related mutation APIs stay open > - A hosted tenant can open Plugins or Adapters, try an action, and hit a confusing failure, because only a few hardcoded platform floors exist > - This pull request adds a generic, operator-configured visibility mechanism: one env var hides declared settings surfaces in the UI and floors their mutation routes with a stable 403 code > - The benefit is a clean hosted-tenant settings surface for any operator, with zero behavior change for normal self-hosted instances ## Linked Issues or Issue Description Subsystem affected Instance settings (server routes and UI), the shared settings registry in `packages/shared`, and the `/api/health` bootstrap payload. Problem or motivation An operator who hosts Paperclip for other people cannot hide settings surfaces that the platform manages. Tenants see Access, Plugins, and Adapters pages, backup retention, and host-level experimental toggles that do nothing useful for them. The mutation APIs behind these surfaces also stay open, so a tenant admin can attempt actions the platform must control. ROADMAP.md names a cleaner shared deployment story as a goal ("Teams should be able to run the same product in hosted or semi-hosted environments without changing the mental model"). Proposed solution Add a declarative registry of hideable settings surfaces and one env var, `PAPERCLIP_HIDDEN_SETTINGS`. The server parses the list at boot, reports it on `/api/health`, and rejects value-changing writes to hidden surfaces with a stable `settings_operator_managed` 403 code. The UI reads the list from the health payload and removes the hidden pages, sections, and toggles from navigation, routes, and page content. Unknown keys warn and are ignored, so one list can roll across a fleet with mixed app versions. With the variable unset, behavior is byte-identical to today. Alternatives considered - Hardcode the hidden set for cloud instances in this repo: rejected, because each hosting operator needs a different policy, and policy does not belong in shared code. - Deliver the hidden set through the managed-config document: rejected, because that channel is cloud-specific and fail-closed on unknown fields; a plain env var works for any operator, including self-hosted shared servers. - Lock the controls with a badge instead of hiding them: rejected for these surfaces, because they are meaningless to tenants, not merely platform-controlled; the existing managed-overlay lock stays the right tool for controlled flags. Roadmap alignment Supports the "shared deployment story" item in ROADMAP.md: hosted and semi-hosted deployments keep the same product with a settings surface that matches what the tenant can actually do. ## What Changed - New `packages/shared/src/settings-visibility.ts`: registry of hideable surfaces (every instance settings page — profile, environments, access, heartbeats, experimental, plugins, adapters; every Instance → General section; every experimental flag as `instance.experimental.<key>`), the `PAPERCLIP_HIDDEN_SETTINGS` parser, and the `settings_operator_managed` error code. The General page stays visible as the settings root and redirect target. - New `server/src/services/settings-visibility.ts`: parse-once accessor; unknown keys log one warning and are ignored. - `/api/health` reports `hiddenSettings` on every response shape; the field is omitted when nothing is hidden. - Server floors on hidden surfaces, with same-value echo tolerance (the `executionMode` precedent): field-backed general sections and experimental keys reject value-changing PATCHes, and hiding the whole Experimental page floors every toggle; plugin lifecycle and config writes, adapter management writes, and the Access admin routes (reads included) return 403 `settings_operator_managed`. Reads the app itself needs (plugin `ui-contributions`, adapter metadata, plugin job trigger) stay open. Pages without instance-scoped mutation routes are hidden in the UI only. - UI: new `useHiddenSettings` hook and `HiddenSettingsPageGate` route gate (hidden pages redirect to the settings root); the settings sidebar and tab bar drop hidden entries; remembered settings paths remap to the default page; `InstanceGeneralSettings` skips hidden sections; every `ExperimentalToggleCard` now carries its flag key and renders nothing when hidden. - Removed the dead `InstanceSidebar` component (referenced only by its own test). - Docs: `docs/deploy/environment-variables.md` documents the variable and the key registry. ## Verification - `pnpm vitest run` over the new and extended suites: shared registry and parser, representative floor tests per route class (changed-value 403, same-value echo 200, unset env 200, page-level Experimental hiding), the health field, the route gate, nav filtering, and section/card hiding with one hidden example per surface kind — 168 tests pass. - Full root `pnpm typecheck` passes. - Manual: booted a server with the variable set. `/api/health` lists the keys; an unknown key logs one warning and the server boots; hidden pages redirect; hidden sections and cards do not render; hidden-field PATCH returns 403 with `details.code = "settings_operator_managed"`; a same-value echo returns 200. Unset the variable: the full settings surface returns and responses are byte-identical to master. ## Risks - Low risk for self-hosted instances: with the variable unset, the hidden set is empty, the health field is omitted, and no floor activates. - Flooring plugin config writes assumes hosted deployments configure plugins through the platform. If a future bundled plugin needs tenant-entered config, the floor needs a narrow carve-out. - Hidden-key floors tolerate same-value echoes, so API clients that round-trip full GET responses keep working. - Hiding a toggle does not change its value; operators pair hiding with the desired default where the value matters. ## Model Used Claude Fable 5 (Anthropic, `claude-fable-5`) with extended thinking and agentic tool use, driven through the Claude Code CLI (file edits, test execution, and live-server verification loops). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 17:54:44 -07:00
David V Claude Opus 4.8 Paperclip Dotta Devin Foley	233c12f029	feat: add kimi-local adapter for Kimi Code CLI (CLI + ACP engines) (#9967 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Local agent adapters (`claude_local`, `gemini_local`, `grok_local`, …) are the integration surface that lets Paperclip run coding CLIs on the host machine > - The Kimi Code CLI (`kimi`, Moonshot AI) has a documented non-interactive mode, `kimi -p --output-format stream-json` with session resume via `kimi -r`, but Paperclip has no built-in adapter for it > - So Kimi users (especially Kimi membership / OAuth subscribers) cannot onboard their CLI to Paperclip agent teams > - This pull request adds a complete built-in `kimi_local` adapter (both execution engines, session management, instructions + skills delivery, thinking-effort control, environment test, UI and CLI modules, docs) following the established `gemini_local`/`grok_local` package pattern > - Kimi Code ships an ACP server (`kimi acp`), so the adapter runs on Paperclip's shared acpx engine by default (streaming transcript with live tool status, like `claude_local`/`gemini_local`) and falls back to a headless CLI lane (`kimi -p --output-format stream-json`) when ACP prerequisites are unavailable > - The benefit is that Kimi Code becomes a first-class Paperclip agent lane: selectable in the UI, resumable across heartbeats, with the same operating context (instruction bundle, skills, effort) and streaming transcript the other local adapters get ## Linked Issues or Issue Description - Supersedes #9880 (same branch; expanded from the CLI-only lane into a complete adapter with the default ACP engine lane, control-plane skill install, and live transcript wiring) - Refs #9879 (adapter request for Kimi Code CLI, filed with this PR) - Refs #163 (original Kimi support request) Duplicate/related prior PRs, per the dedup search (both appear stale: no updates or maintainer review since May 2026, and both target an older Kimi CLI interface; calling them out for reviewer context per CONTRIBUTING.md): - Refs #6276 (`feat: add kimi-local adapter`): targets an older array-based content format (`{type: think}`/`{type: text}` blocks), not the current documented stream-json schema - Refs #5202 (`feat(adapter): add Kimi CLI local adapter with Wire protocol support`): builds on a `--wire` JSON-RPC interface that current Kimi Code CLI (0.27.0) no longer documents; the current documented headless interface is `-p --output-format stream-json` This PR is a fresh implementation against current master and the currently documented/verified Kimi CLI behavior (see Verification). Happy to fold in anything useful from the earlier attempts if a reviewer prefers. ## What Changed - New adapter package `packages/adapters/kimi-local` (`@paperclipai/adapter-kimi-local`), modeled on `gemini-local`/`grok-local`: - `src/server/execute.ts`: spawns `kimi -p <prompt> --output-format stream-json` (argv array, no shell), `-m <model>` only when configured, `-r <sessionId>` when the stored session cwd matches the run cwd, automatic fresh-session retry on unrecoverable-session errors, headless-safe env (`CI=1`, `NO_COLOR=1`, `KIMI_CODE_NO_AUTO_UPDATE=1`, `TERM=dumb`; user-configured values win), full remote (ssh/sandbox) execution lane with runtime install via `@moonshot-ai/kimi-code` - Instruction bundle delivery: the prompt path directive now names the sibling instruction files (`./HEARTBEAT.md`, `./SOUL.md`, `./TOOLS.md`) alongside the prepended entry file, and local runs pass `--add-dir <instructions-dir>` so Kimi can actually open them (matching `claude_local`). Without this, only the entry file reached Kimi and agents improvised the operating workflow that `HEARTBEAT.md` documents - Thinking effort: a configured `effort` is forwarded as the `KIMI_MODEL_THINKING_EFFORT` operational override (Kimi has no per-invocation effort flag). It is only sent for models that advertise `support_efforts` (currently `kimi-code/k3`) to avoid provider rejections, and `medium` maps to `high` since Kimi has no medium tier (`low`/`high`/`max` pass through) - Skills delivery: desired Paperclip skills are delivered via Kimi's `--skills-dir` flag from a dedicated per-run directory (a local snapshot, or the synced snapshot on remote targets), so skills load reliably and in isolation. Paperclip never overwrites the shared `$KIMI_CODE_HOME/skills` home, so skills installed by the operator or other agents are left intact. `--skills-dir` is only passed when at least one skill is desired, so unconfigured agents keep Kimi's default skill discovery - Live run status: the adapter now forwards each streamed stream-json line to `onEvent` (assistant `content` as an assistant snippet, `tool_calls` as tool-name events), which drives the issue-thread activity indicator (`currentToolName` / `lastAssistantSnippet` / `lastEventAt`). Previously the adapter only wrote the raw run log, so the issue thread showed a stale "no output for N s" line with no tool or reasoning context while Kimi worked. Tool results are omitted so the last meaningful "Using X" / snippet is not overwritten by a generic label - `src/server/parse.ts`: parses the verified Kimi stream-json event shapes (`assistant` text, `assistant.tool_calls` with JSON-string arguments, `tool` results, trailing `meta.session.resume_hint` for session-id capture) plus failure classifiers (`kimi_auth_required`, transient network, unrecoverable session). A signaled exit (null exit code, not a timeout) is now reported as a failure rather than coalesced to success, and the error message names the terminating signal - `src/server/skills.ts`: lists/syncs Paperclip skills for the adapter's skill-management surface - `src/server/test.ts`: environment test covering CLI resolution + `kimi --version`, cwd check, auth detection (OAuth credential dirs, keyed `[providers.]` in config.toml, or the `KIMI_MODEL_NAME` + `KIMI_MODEL_API_KEY` env pair), and a live hello probe - `src/ui/` (stdout-line parser for transcripts, config builder) and `src/cli/` (stream event formatter) modules - Root metadata: three managed model aliases (`kimi-code/kimi-for-coding`, `kimi-code/kimi-for-coding-highspeed`, `kimi-code/k3`), effort-capable-model metadata (`EFFORT_CAPABLE_MODELS`, effort mapping helpers), `agentConfigurationDoc` - Tests: 101 tests across parse, execute (args building, resume gating, retry, auth error code, timeout, signaled-exit failure, effort forwarding/gating/mapping, `--add-dir` instructions directive, `--skills-dir` gating, `onEvent` runtime-event forwarding), ACP engine (engine resolution, acpx config build, node-version gate), ACP transcript delegation, environment test, UI parse/build-config - ACP engine lane (default)* (`src/server/acp.ts` + shared `adapter-utils/acpx-engine`): Kimi Code ships an ACP server (`kimi acp`), so `kimi_local` now runs on Paperclip's shared acpx engine by default, matching `claude_local`/`codex_local`/`gemini_local`. The issue-thread transcript streams live (assistant text deltas, tool calls with a `pending`->`completed` status lifecycle) instead of the CLI lane's bursty complete-message output. Registered `kimi_local -> "kimi"` in `ACPX_ADAPTER_AGENT_IDS` and resolved the built-in agent command to `kimi acp`; `execute.ts` dispatches to the ACP executor first with an automatic CLI fallback when ACP prerequisites fail (`engine=acp` requires ACP, `engine=cli` pins the headless lane); `index.ts` falls back to the shared acpx session codec; the UI/CLI delegate `acpx.` events to the shared acpx transcript parser and event formatter. The headless CLI lane (above) remains as the fallback - Registration* (one entry each, mirroring existing adapters): server adapter registry + `BUILTIN_ADAPTER_TYPES`, `AGENT_ADAPTER_TYPES` (shared), UI adapter registry + display registry (`Kimi Code`, Moon icon) + capabilities defaults, CLI adapter registry, `Dockerfile` (package copy + `npm install --global @moonshot-ai/kimi-code@latest`), `vitest.config.ts` workspace, `scripts/release-package-manifest.json` - Behavioral sets mirroring `gemini_local` (Kimi resumes sessions the same way): `GIT_SENSITIVE_LOCAL_ADAPTER_TYPES`, `SESSIONED_LOCAL_ADAPTERS` (heartbeat + recovery), `REMOTE_MANAGED_ADAPTERS`, ssh/sandbox execution-target allow-lists, `ADAPTER_DEFAULT_RULES_BY_TYPE` (`timeoutSec: 0`, `graceSec: 15`), and `LEGACY_SESSIONED_ADAPTER_TYPES` + `ADAPTER_SESSION_MANAGEMENT` in adapter-utils - UI touch-points: New Agent default-model branch, AgentConfigForm command map (`kimi_local: "kimi"`) + model defaults + a Kimi-specific thinking-effort option list (`Low`/`High`/`Max`, reflecting Kimi's tiers rather than borrowing Claude's), OnboardingWizard (command map, model default, `kimi login` / `KIMI_MODEL_NAME + KIMI_MODEL_API_KEY` auth hints, manual-debug command line), InviteLanding enabled adapters - Control-plane skill install (`cli/src/commands/client/agent.ts`): `paperclipai agent local-cli` seeded the Paperclip control-plane skills into `~/.codex/skills` and `~/.claude/skills` so Codex/Claude agents auto-discover the API reference every run. Kimi had no equivalent target, so `kimi_local` agents began each session without the control-plane skill and rediscovered routes (e.g. the company-scoped `POST /api/companies/{companyId}/issues`) by trial and error. Added `~/.kimi-code/skills` (honoring `KIMI_CODE_HOME`) as a third install target for parity. Independent of the per-run `--skills-dir` delivery, which only applies to explicitly configured skills. - Docs: `docs/adapters/kimi-local.md` (prerequisites, auth options, config fields including `effort`, session resume, instruction bundle, skills delivery, control-plane skill install) + a row in `docs/adapters/overview.md` Out of scope (deliberately): model profiles, built-in agent `allowedAdapterTypes` additions. ## Verification\n\nCurrent-master rebase verification (OpenAI Codex, 2026-08-03): 13 focused files / 231 tests pass; adapter-utils, server, UI, CLI, and Kimi adapter typechecks pass; full repository build and UI token gates pass. The branch is conflict-free against master at head `1249df117c5e12e5771b9a570a6340866450619e`.\n\nAutomated (all from repo root, pnpm 9.15.4, Node 22): - `vitest run packages/adapters/kimi-local`: 89/89 pass (includes coverage for the instruction `--add-dir` directive, effort forwarding/gating/mapping, `--skills-dir` gating, the signaled-exit failure path, and `onEvent` runtime-event forwarding with cross-chunk line buffering) - `vitest run server/src/__tests__/adapter-registry.test.ts server/src/__tests__/adapter-routes.test.ts server/src/services/heartbeat-stop-metadata.test.ts ui/src/adapters/adapter-display-registry.test.ts`: 37/37 pass - `vitest run cli/src/__tests__/skills.test.ts`: 13/13 pass (the control-plane skill install target follows the existing Codex/Claude install path, whose symlink logic is unchanged) - `vitest run packages/shared`: 307/307 pass; `vitest run packages/adapter-utils`: pass except one pre-existing, unrelated failure (`mcp-isolation.integration.test.ts` requires Claude CLI ≥ 2.1.207; host has 2.1.185, fails identically on unmodified master) - `pnpm --filter @paperclipai/adapter-kimi-local typecheck\|build`, plus typecheck of `server`, `ui`, `cli`, `adapter-utils`: all clean - `pnpm install --frozen-lockfile`: passes (the PR diff itself contains no lockfile changes, per repo policy; verified against a locally regenerated lockfile) - `node scripts/check-no-git-push.mjs` and `node scripts/check-forbidden-tokens.mjs`: pass - CI note: the `policy` job's release-bootstrap step is expected to stay red until a maintainer bootstraps the first npm publish of `@paperclipai/adapter-kimi-local`; see the CI Note for Maintainers comment. All other contributor-actionable checks are green. Manual end-to-end (real Kimi CLI 0.27.0, OAuth login, dev server on an isolated instance): 1. Server `GET /api/adapters` lists `kimi_local` as builtin with correct capability flags; models endpoint returns the three Kimi models 2. `POST .../adapters/kimi_local/test-environment`: all checks pass, including a live `kimi -p` hello probe 3. Created a `kimi_local` agent and invoked two heartbeats: run 1 spawned `kimi -p ... --output-format stream-json`, Kimi used its `Read` tool, produced the expected answer, and the session id was captured from the `session.resume_hint` meta event; run 2 resumed the same Kimi session (`sessionIdBefore == sessionIdAfter`) via `-r` 4. UI: adapter appears in the New Agent dropdown; selecting it shows the Kimi command placeholder, the three models, and the Kimi config fields; the run transcript renders Kimi tool calls via the adapter's stdout parser The instruction-bundle, thinking-effort, and `--skills-dir` changes landed after the manual run above. They are covered by the unit tests listed under Automated, and the Kimi CLI flags they rely on (`--add-dir`, `--skills-dir`, `KIMI_MODEL_THINKING_EFFORT`) were confirmed against the installed Kimi Code CLI 0.27.0 (`kimi --help`, config-file thinking-effort docs). Screenshots (assets branch on the fork, not part of the diff): ![Kimi Code in the Add a new agent runtime picker](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/00-kimicode.png) ![Adapter dropdown with Kimi Code](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/01-adapter-dropdown-kimi.png) ![Kimi adapter selected: command, model, config fields](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/02-kimi-adapter-selected.png) ![Kimi models in the model dropdown](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/03-kimi-model-dropdown.png) ![Successful resumed heartbeat run (kimi_local invocation + parsed transcript)](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/04-successful-resumed-run.png) ![Agents list showing the Kimi Code label](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/05-agents-list.png) ## Risks - Low risk to existing behavior: the change is additive, one new workspace package plus single-entry registrations alongside existing adapters; no existing adapter code paths are modified. - The adapter invokes the locally installed `kimi` CLI; like other local adapters, run behavior depends on the host's Kimi version. The parser is written against the documented/verified 0.27.0 stream-json schema and degrades gracefully (malformed lines are skipped, failures surface as run errors). - `--skills-dir` overrides Kimi's auto-discovery of user and project skills for the run. This is intentional (paperclip-managed agents get a reproducible, isolated skill set), and it is only passed when at least one Paperclip skill is desired, so unconfigured agents keep default discovery. - Thinking effort is only forwarded to models that advertise `support_efforts` (currently `kimi-code/k3`); `EFFORT_CAPABLE_MODELS` must be extended when more Kimi models gain support, otherwise a configured effort is silently ignored for them. - `Dockerfile` now installs `@moonshot-ai/kimi-code@latest` globally alongside the other agent CLIs, so image size increases slightly. - Maintainer action needed for the npm bootstrap gate: the `policy` job's release-bootstrap step fails until the first npm publish of `@paperclipai/adapter-kimi-local` (the gate from #5146 that every new adapter package has passed through). Enrollment with `publishFromCi: true` is required by the manifest validator (dropping the entry, `false`, or `private` are all rejected), so this is intentionally left to a maintainer. Remaining CI lanes are expected to run once it is done. ## Model Used\n\n- Current-master rebase, conflict adaptation, and registry-parity coverage: OpenAI, GPT-5 Codex (Codex agent; exact serving model ID and context-window size were not exposed to the runtime), with repository, shell, Git, and GitHub tooling. It preserved Hawik’s commit authorship, reconciled ACPX and environment-capability changes, added current registry tests, and ran the verification above.\n- Adapter implementation and initial review: Moonshot AI, Kimi K3 Coding (latest), via Kimi Code CLI v0.27.0 (`kimi-code/k3` alias, 1M-token context window, thinking mode, agentic tool use). The CLI agent explored the repo, wrote the adapter implementation (delegated to a coder sub-agent of the same model), ran tests, and drafted the first version of this PR body. A second model-driven review pass (read-only, same model) audited the diff for security/correctness before submission; its findings (shell-quoting hardening, auth-detection false positive, session-compaction registration, test gaps) were fixed and are included. - Harness-context fixes and review responses: Anthropic, Claude Opus 4.8 (`claude-opus-4-8`) via Claude Code. Diagnosed from run logs that Kimi received only the entry instructions file (not the `HEARTBEAT.md`/`SOUL.md`/`TOOLS.md` bundle) and that `effort` was never wired, then implemented the instruction `--add-dir` delivery, `KIMI_MODEL_THINKING_EFFORT` forwarding, and `--skills-dir` skill delivery, added the accompanying tests and docs, and addressed the automated review comments (preserving external skills on remote sync, treating a signaled exit as a failure). Also extended the `paperclipai agent local-cli` installer to seed the control-plane skills into `~/.kimi-code/skills` for Codex/Claude parity, wired `onEvent` runtime events so the issue-thread activity indicator reflects Kimi's tool and reasoning output live, and built the ACP engine lane (`kimi acp` via the shared acpx engine, default) so the transcript streams with live tool status like the other ACP adapters. The Kimi CLI flags, subcommand, and env var relied on here were verified against the installed Kimi Code CLI 0.27.0. - All CLI behaviors claimed here (`-p`, `--output-format stream-json`, `-r` resume, event shapes, `--add-dir`, `--skills-dir`, `KIMI_MODEL_THINKING_EFFORT`) were verified empirically against the installed Kimi CLI, not assumed. ## 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 (only the release-bootstrap step remains red, pending the maintainer npm publish described in Risks) - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups (will address all Greptile comments as they arrive) - [x] I will address all Greptile and reviewer comments before requesting merge --- ## Maintainer Addendum (2026-08-20) The shared acpx-engine and issue-chat changes (run-summary segmentation, placeholder tool-event coalescing, `ISSUE_CHAT_TRANSCRIPT_MAX_VISIBLE_ENTRIES` 30 → 400, live-reasoning UI) have been extracted to #11761 so the cross-adapter behavior changes review and revert independently — both commits there preserve @hawikk's authorship. This PR is now the kimi-specific adapter only (60 files, +3,793/−8, essentially pure addition); the only shared-engine touch left is the `kimi acp` command resolution. `publishFromCi` is `true` — the package name is bootstrapped on npm. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Dotta <bippadotta@protonmail.com> Co-authored-by: Devin Foley <devin@paperclip.ing>	2026-08-20 12:06:33 -07:00

... 3 4 5 6 7 ...