2524 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Devin Foley	524e18b060	ci: use runner Chrome for headless workflows (#6967) ... ## Thinking Path > - Paperclip relies on CI browser suites to protect control-plane workflows, so a stalled browser bootstrap is a release blocker even when app code is unchanged. > - The failing signal on [PAPA-457](/PAP/issues/PAPA-457) was specific to the PR e2e lane timing out before tests started, which pointed at environment setup rather than assertions. > - The first shell-only Chromium attempt reduced download size, but the GitHub Actions log showed Playwright still hanging inside its install step after the headless shell download finished. > - That means the real problem is the Playwright browser-install path itself on the hosted Ubuntu runner, not just the size of the downloaded artifact. > - GitHub's Ubuntu runners already ship Google Chrome, and Playwright can target that binary through the `chrome` channel without downloading its own Chromium bundle. > - The safer workflow fix is therefore to remove the Playwright install step from the affected headless jobs and make the Playwright configs optionally use runner Chrome only when CI opts into it. > - This keeps local defaults unchanged, removes the failing browser-download dependency from CI, and preserves headless coverage for PR, standalone e2e, and release-smoke workflows. ## What Changed - Updated `.github/workflows/pr.yml`, `.github/workflows/e2e.yml`, and `.github/workflows/release-smoke.yml` to stop downloading Playwright browsers and instead verify the runner's preinstalled `google-chrome`. - Passed `PAPERCLIP_PLAYWRIGHT_CHANNEL=chrome` into the headless PR, standalone e2e, and release-smoke test steps so those jobs explicitly use runner Chrome. - Updated `tests/e2e/playwright.config.ts` and `tests/release-smoke/playwright.config.ts` to honor `PAPERCLIP_PLAYWRIGHT_CHANNEL` while keeping the default local/browser-bundle behavior unchanged when the env var is absent. ## Verification - Investigated the failed PR run log and confirmed the prior `Install Playwright` step stalled after `chromium-headless-shell` reached 100% download. - `PLAYWRIGHT_BROWSERS_PATH="$(mktemp -d)" PAPERCLIP_PLAYWRIGHT_CHANNEL=chrome PAPERCLIP_E2E_SKIP_LLM=true pnpm run test:e2e` Result: `7 passed (21.1s)` with an empty temporary Playwright browser cache, proving the e2e suite runs without any Playwright browser download when the `chrome` channel is selected. - `git diff --check` ## Risks - This assumes GitHub's Ubuntu runner continues to ship `google-chrome`; if that image contract changes, these workflows would need a dedicated Chrome install step. - The `chrome` channel can differ slightly from Playwright-managed Chromium, so the config gate is intentionally env-scoped to CI workflows that need the hosted-runner path. ## Model Used - OpenAI Codex, GPT-5-based coding agent running through Paperclip's `codex_local` adapter with tool use, shell execution, and repository editing enabled. The exact internal snapshot/version string is not exposed in-session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [ ] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-29 00:18:52 -07:00
Devin Foley	d9f91576a0	Add accepted-plan decomposition exact-once guards and UI state (#6831) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, so planning approvals and child-issue fan-out are part of the core control-plane loop. > - Accepted plans are supposed to be a safe bridge from planning into execution, especially when agents wake from review decisions and reuse isolated workspaces. > - The duplicate-subtask incident showed that an accepted plan revision could be interpreted more than once across overlapping runs, which broke the single-source-of-truth model for issue decomposition. > - Fixing that required tightening the backend contract first: accepted-plan decomposition needs an exact-once fingerprint, durable claim state, and retry-safe child creation. > - Once that backend behavior existed, the board still needed visibility into what happened, so the issue detail view needed a dedicated decomposition section instead of forcing operators to reconstruct child creation from raw activity. > - This pull request adds the exact-once decomposition primitive, hardens wake routing and regressions around the incident, and surfaces decomposition state in the UI so future incidents are both prevented and easier to inspect. ## What Changed - Added accepted-plan decomposition semantics to `doc/execution-semantics.md`, including the exact-once fingerprint, durable claim/result expectations, and retry/resume behavior. - Added persistent accepted-plan decomposition claims in the backend, including schema, shared types/validators, service logic, and issue routes for creating and listing decomposition state. - Hardened heartbeat routing so an accepted-plan continuation stays scoped to the relevant planning issue instead of opportunistically re-decomposing another accepted issue on the same assignee. - Added regression coverage for the original failure modes: concurrent same-parent retries, cross-issue accepted-plan isolation, and partial child recreation under the same fingerprint. - Added the `Plan decomposition` issue-detail section plus supporting API/query-key/activity formatting updates so operators can see revision status, owner, child counts, and the linked child issues directly in the UI. - Included the small follow-up UI fix so the decomposition section still renders when the issue work mode is no longer `planning`. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm --filter @paperclipai/db typecheck` - `pnpm exec vitest run server/src/__tests__/issues-service.test.ts` - `pnpm exec vitest run server/src/__tests__/issues-service.test.ts -t "lists persisted decompositions with child issue summaries"` - `pnpm exec vitest run server/src/__tests__/issues-service.test.ts -t "accepted plan decomposition" server/src/__tests__/heartbeat-accepted-plan-workspace-refresh.test.ts server/src/__tests__/heartbeat-context-summary.test.ts` - Manual UI path: create a planning issue without an isolated execution workspace, add a `plan` document, accept the `request_confirmation`, let Paperclip create child issues, then reopen the parent issue detail page and confirm the `Plan decomposition` section shows the accepted revision, status, idempotent-claim badge, and child links. - Separate follow-up bug noted during manual UI validation: accepting a plan on an issue whose run never records `workspace_finalize` is tracked in `PAPA-445` and is not part of this PR’s fix scope. ## Risks - This adds a new migration and a large Drizzle snapshot update; reviewers should confirm the schema shape and generated metadata match the intended decomposition table. - The exact-once claim changes sit on the accepted-plan fan-out path, so regressions there could block legitimate child creation or mis-handle retries if the claim state machine is wrong. - The new UI only appears when decomposition records exist; reviewers should use the manual verification path above rather than expecting existing issues on a stale local instance to show the section automatically. - `PAPA-445` remains an open follow-up for the `workspace_finalize` accept gate when a planning handoff never records finalize; that bug can interfere with reproducing the UI flow on isolated workspaces but does not change the correctness of the exact-once decomposition feature itself. > Checked `ROADMAP.md`: this PR is a bug fix / control-plane hardening change for accepted-plan decomposition, not a new uncoordinated roadmap feature. ## Model Used - OpenAI Codex via Paperclip `codex_local` (GPT-5-based coding agent; exact backend model ID/context window not exposed in the run context), with repository tool use, shell execution, and code-editing capabilities. <img width="806" height="1069" alt="Screenshot 2026-05-27 at 11 05 48 PM" src="https://github.com/user-attachments/assets/5b00b670-96cd-4470-b0a3-581743bcae28" /> ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-28 23:30:18 -07:00
Dotta	9eac727cf1	[codex] Add skills CLI and catalog management (#6782) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies through company-scoped control-plane workflows. > - Agents need reusable, inspectable skills that can be installed, reset, audited, exported, and assigned without bespoke local setup. > - The existing skill truth model needed cleanup so bundled skills, optional catalog skills, runtime skills, and adapter-provided skills have clear provenance. > - Operators also need a practical CLI and board UI for discovering and managing company skills. > - This pull request adds the skills CLI, packaged skills catalog, company skills APIs, and catalog-aware board UI. > - The benefit is a more reusable Paperclip company setup where skills are portable, auditable, and easier for operators and agents to manage. ## What Changed - Added `paperclipai skills` CLI commands and coverage for catalog listing, installing, resetting, and inspecting company skills. - Added a packaged `@paperclipai/skills-catalog` workspace with bundled and optional skill content plus validation/build tests. - Added shared company-skill types and validators used across CLI, server, and UI contracts. - Added server catalog APIs/services for company skill catalog operations, reset semantics, audit behavior, and portability provenance. - Updated adapter skill handling so runtime/catalog provenance remains explicit across local adapters. - Added board UI support for browsing and managing catalog-backed company skills. - Updated docs for the skills CLI/catalog flow and the company skills Paperclip skill reference. - Rebased the branch onto current `paperclipai/paperclip:master`; no `pnpm-lock.yaml`, `.github/workflows`, or migration files are included in the final PR diff. ## Verification - Passed: `pnpm run preflight:workspace-links && pnpm exec vitest run cli/src/__tests__/skills.test.ts packages/skills-catalog/src/catalog-builder.test.ts packages/skills-catalog/src/shipped-catalog.test.ts packages/shared/src/validators/company-skill.test.ts packages/adapter-utils/src/server-utils.test.ts packages/plugins/create-paperclip-plugin/src/entrypoints.test.ts server/src/__tests__/company-skills-catalog-service.test.ts server/src/__tests__/company-skills-routes.test.ts server/src/__tests__/company-portability.test.ts`. - Passed: `pnpm exec vitest run server/src/__tests__/workspace-runtime.test.ts -t "default branch|origin/master|symbolic-ref"`. - Attempted: full `server/src/__tests__/workspace-runtime.test.ts`. Four provisioning tests failed while seeding an isolated worktree database from the local Paperclip instance because the local plugin schema dump contains a duplicate-column foreign key (`plugin_content_machine_18a7bc327b.content_case_signals`). The default-branch tests touched by the rebase conflict passed in the focused run above. - Checked final diff: no `pnpm-lock.yaml`, no `.github/workflows`, and no migration-file changes relative to `master`. ## Risks - Medium: this is a broad skills/catalog change touching CLI, server APIs, shared contracts, adapter skill sync, and UI. - Catalog validation and reset semantics need careful reviewer attention because they affect reusable company setup and portability. - No database migrations are included in this PR, so there is no migration ordering/idempotency risk in the final diff. - No lockfile is included by design; dependency resolution will be handled by the repository lockfile workflow. ## Model Used - OpenAI Codex coding agent based on GPT-5, running in Paperclip via the `codex_local` adapter with shell, git, GitHub CLI, and code-editing tool access. Exact hosted model build/context-window metadata is not exposed in this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run targeted tests locally and documented the local workspace-runtime seed failure above - [x] I have added or updated tests where applicable - [x] If this change affects the UI, screenshots were intentionally omitted per PAP-10124 instructions; UI behavior is covered by tests and reviewer inspection - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-28 07:33:51 -10:00
Dotta	8da50dbcf8	[codex] Add private browser first-admin claim flow (#6755) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Fresh self-hosted deployments need an operator path before any invite exists. > - Umbrel installs are private LAN deployments, so a one-time browser claim is appropriate only when the deployment is private and unclaimed. > - Public deployments and installs with active invites must keep the existing invite-only model so admin creation is not exposed broadly. > - GitHub PR #2927 established the useful direction, but it needed to be adapted onto current `master` rather than merged as-is. > - This pull request adds that adapted private-only claim flow across server, UI, docs, and regression coverage. > - The benefit is that a fresh private Umbrel-style install can be claimed from the browser without weakening public deployment access. ## What Changed - Added a first-admin claim service and access route support for one-time admin claim eligibility on private unclaimed deployments. - Updated the bootstrap/access UI so eligible private installs show a setup claim path, while public and invited deployments keep invite-first behavior. - Added a bootstrap-pending setup UX lab covering claim, invite, public, and signed-in access states. - Updated deployment and local development docs for authenticated private/public behavior and the Umbrel-style claim path. - Added server and UI regression tests for private claim, public no-claim, active invite fallback, existing board/no-access flows, and health exposure reporting. - Stabilized PR handoff verification by serializing the aggregate server Vitest workspace run, forcing `NODE_ENV=test`, and relaxing the heartbeat batching test around legitimate recovery follow-up runs. ## Verification - `pnpm -r typecheck` - `pnpm build` - `pnpm vitest --run server/src/__tests__/heartbeat-comment-wake-batching.test.ts` - `pnpm vitest --run server/src/__tests__/health-dev-server-token.test.ts` - `pnpm test:run` - QA validation: PAP-10115 passed browser validation with screenshots for private fresh install claim, active invite versus claim conflict, public invite-only/claim-absent behavior, existing invite fallback, and normal board/no-access flows. - GitHub closeout: issue #2579 and PR #2927 were updated with the accepted direction: adapt the implementation, do not direct-merge #2927 as-is. ## Risks - The claim endpoint must remain private-only and one-time; a regression here could expose admin creation on public deployments. - Existing invite behavior must remain intact for public deployments and installs that already have an active invite. - The stable Vitest harness now serializes the aggregate server workspace group; this is slower, but it avoids DB-backed suite collisions under root workspace mode. > 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`. > > ROADMAP.md checked: this is a scoped deployment bootstrap/access fix and does not duplicate a listed roadmap project. ## Model Used - OpenAI GPT-5 Codex via Paperclip `codex_local` for product engineering, implementation, and verification, with tool-enabled local code execution. Paperclip QA browser validation was performed in PAP-10115 by the assigned QA agent; exact adapter model metadata for that QA run is not exposed in this PR context. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-27 21:15:01 -10:00
Devin Foley	de36743583	docs(readme): align README with brand guidelines (PAPA-439) (#6810) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The README is the first impression for developers and operators landing on the repo, so it has to reflect the current brand voice and visual identity > - The existing README leads with an outdated hero ("Open-source orchestration for zero-human companies"), keeps a board-centric tagline that no longer matches the positioning, advertises a removed COMING SOON teaser, and still uses an old header image and an unnecessary footer image > - Out-of-date positioning at the top of the README undercuts the rest of the doc and the brand guidelines refresh at https://paperclip.ing/brand > - This pull request swaps the README header image for the new brand banner, updates the hero copy and tagline, and trims stale callouts so the README matches the new brand guidelines > - The benefit is a README that leads with the current positioning ("Paperclip is the app people use to manage AI agents for work.") and current visual identity, with no stale teasers or extraneous footer image ## What Changed - Added new brand banner at \`doc/assets/banner.jpg\` and pointed the README header \`<img>\` at it (alt text updated to the new tagline) - Replaced the \`## What is Paperclip?\` + \`# Open-source orchestration for zero-human companies\` heading pair with a single H1: \`# Paperclip is the app people use to manage AI agents for work.\` - Tightened the opening paragraphs ("Open-source orchestration for teams of AI agents.", trimmed dashboard sentence, "Under the hood:" line, period on the OpenClaw/Paperclip tagline) - Removed the \`COMING SOON: Clipmart\` callout - Softened the Governance copy by dropping "You're the board." in both the Features grid and the Systems table - Fixed typo: "solo-entreprenuer" → "solo entrepreneur" - Removed the README footer image block entirely - Updated the closing subline: "Built for people who want to run companies, not babysit agents." → "Built for people who want to get work done, not babysit agents." - Left existing assets untouched on disk: \`doc/assets/header.png\` and \`doc/assets/footer.jpg\` are unchanged from master (only the README references changed) ## Verification - \`git diff master..HEAD --stat\` → only \`README.md\` (10+/18-) and the new \`doc/assets/banner.jpg\` - Rendered the README locally and confirmed: - The header banner shows the new brand image - The H1 reads "Paperclip is the app people use to manage AI agents for work." - No COMING SOON Clipmart callout - No footer image; closing subline reads "Built for people who want to get work done, not babysit agents." - No code paths changed; no test suite applies ## Risks - Low risk. Docs-only change. \`cli/README.md\` still references the on-master URL for \`doc/assets/header.png\`, which is intentionally left in place so that link does not break. ## Model Used - Claude (Anthropic), model id \`claude-opus-4-7\` ("Opus 4.7"), running under Claude Code via the Paperclip claude_local adapter. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass (n/a — docs-only) - [x] I have added or updated tests where applicable (n/a — docs-only) - [x] If this change affects the UI, I have included before/after screenshots (n/a — README-only; rendered review described in Verification) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Closes PAPA-439	2026-05-27 18:18:00 -07:00
Devin Foley	a49afe5ea1	docs: update README license to Paperclip Labs, Inc (PAPA-437) (#6804) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The repository README closes with a license/copyright line that downstream readers use to identify the legal entity behind the project > - The line currently reads "MIT © 2026 Paperclip", which omits the formal corporate name > - The legal entity is "Paperclip Labs, Inc"; the README should reflect that for accuracy > - This pull request updates the README footer to "MIT © 2026 Paperclip Labs, Inc" > - The benefit is correct attribution of the MIT license to the actual legal entity ## What Changed - Updated `README.md` license line from "MIT © 2026 Paperclip" to "MIT © 2026 Paperclip Labs, Inc" ## Verification - Open `README.md` and confirm the final line reads `MIT © 2026 Paperclip Labs, Inc` - No code paths affected; no tests required ## Risks - Low risk — single-line documentation change, no runtime impact ## Model Used - Provider: Anthropic Claude - Model ID: claude-opus-4-7 - Capabilities: tool use, code execution 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 run tests locally and they pass (N/A — docs-only change) - [x] I have added or updated tests where applicable (N/A) - [x] If this change affects the UI, I have included before/after screenshots (N/A — no UI change) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-27 15:07:02 -07:00
Dotta	b7545823be	[codex] Add document annotations and comments (#6733) ... ## Thinking Path > - Paperclip orchestrates AI-agent companies through issues, documents, runs, and durable company-scoped state. > - Issue documents are where agents and operators capture plans, handoffs, and work products. > - Before this change, document collaboration could only happen through whole-document edits and detached issue comments. > - Inline document annotations need stable anchors, revision-aware persistence, and UI affordances that do not break existing document editing. > - This pull request adds company-scoped document annotation threads, comments, anchor snapshots, API routes, and board UI. > - The benefit is that operators and agents can discuss specific document passages without losing context as documents evolve. ## What Changed - Added document annotation tables, schema exports, shared types, validators, anchor hashing, and text-anchor helpers. - Added server-side document annotation services and issue routes for listing, creating, commenting, resolving, and reopening annotation threads. - Included annotation summaries in relevant issue document reads and backup/recovery document workspace behavior. - Added React UI for inline document highlights, comment panels, mobile sheet behavior, deep-link focus, and resolved/open filtering. - Added annotation design artifacts, Storybook coverage, screenshots, and a screenshot helper script. - Rebased the branch onto current `paperclipai/paperclip` `master` and renumbered the annotation migration from `0085_old_swarm` to `0091_old_swarm`; the SQL uses `IF NOT EXISTS` guards so environments that previously applied the old migration number can safely apply the new one. - Adjusted the new annotation UI tests to use a local async flush helper because this workspace's React 19.2.4 export does not expose `React.act`. ## Verification - `pnpm run preflight:workspace-links && pnpm exec vitest run packages/shared/src/document-anchors.test.ts server/src/__tests__/document-annotation-routes.test.ts server/src/__tests__/document-annotations-service.test.ts ui/src/components/DocumentAnnotationLayer.test.tsx ui/src/components/IssueDocumentAnnotations.test.tsx ui/src/lib/document-annotation-hash.test.ts ui/src/lib/document-annotation-selection.test.ts` - Confirmed `git diff --check` passes. - Confirmed no `pnpm-lock.yaml` or `.github/workflows/*` files are included in the PR diff. ## Risks - Medium risk: this adds new persisted annotation tables and routes across db/shared/server/ui. - Migration risk is reduced by moving the branch migration to `0091_old_swarm` after upstream `0090_resource_memberships` and keeping the SQL idempotent for old `0085_old_swarm` adopters. - UI risk is mostly around text range anchoring and panel positioning across long documents, folded content, and mobile layouts; the PR includes focused unit coverage and design screenshots. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent, tool-using software engineering mode. Context window size is not exposed in this Paperclip runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-26 06:41:23 -07:00
Dotta	f0ddd24d61	[codex] Show bundled plugins in plugin manager (#6734) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - The plugin system is how Paperclip exposes optional capabilities and integrations without bloating the control plane. > - Operators need the Instance Settings plugin manager to show both installed external plugins and bundled built-in plugins. > - Bundled plugins were available in the server/UI surface but were not represented consistently in the plugin manager list. > - Workspace runtime reuse also needed to stay pinned to the current branch/base so the plugin manager can be validated from the intended checkout. > - This pull request shows bundled plugins in the manager, marks experimental bundled plugins clearly, and tightens runtime/worktree reuse guards. > - The benefit is that operators can discover bundled plugins from the same management screen as installed plugins without stale workspace sessions hiding the latest branch state. ## What Changed - Lists bundled monorepo plugin packages through the plugin routes API, including plugin status and install metadata needed by the UI. - Updates the plugin manager UI/API client to render bundled plugins and display experimental badges based on installed plugin records. - Adds server authorization coverage around plugin routes so board and agent access stay company-scoped. - Guards execution workspace/runtime reuse against stale base refs and defaults new worktrees to the fetched target base. - Expands workspace runtime tests for service reuse, stale workspace prevention, and controlled runtime stops. - Addressed Greptile feedback by respecting `origin/HEAD`, using async cached bundled-plugin discovery, and avoiding duplicated UI experimental plugin lists. ## Verification - `pnpm exec vitest run server/src/__tests__/plugin-routes-authz.test.ts server/src/__tests__/workspace-runtime.test.ts server/src/__tests__/heartbeat-workspace-session.test.ts` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm --filter @paperclipai/plugin-sdk build && pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server typecheck` - `gh pr checks 6734 --repo paperclipai/paperclip` reports all checks passing on `10e1ba9e0f505637cd913713fb28c2c99ae92011`. - Greptile Review reports 5/5 on `10e1ba9e0f505637cd913713fb28c2c99ae92011`. - Confirmed the branch is rebased onto `public-gh/master` and the PR diff does not include `pnpm-lock.yaml` or `.github/workflows` changes. - UI screenshots were not captured in this PR-creation pass because the available local board runtime is authenticated; the visible UI path is covered by the plugin manager code changes and server/API tests above. ## Risks - Medium risk: this touches shared plugin listing behavior and workspace runtime reuse, so regressions could affect plugin manager visibility or service reuse across execution workspaces. - No database migrations. - No lockfile or GitHub workflow 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 GPT-5 Codex, coding-agent workflow with shell/tool use in a local Paperclip worktree. Context window not surfaced by the runtime; reasoning mode not externally reported. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-26 07:32:45 -06:00
Dotta	9aea3e3d35	[codex] Add resource membership controls (#6677) ... ## Thinking Path > - Paperclip orchestrates AI-agent companies through company-scoped issues, projects, agents, and board-visible workflows. > - The board sidebar and project list are the daily navigation surface for that control plane. > - Users need to keep all projects and agents accessible while hiding resources they have intentionally left from their own sidebar. > - That requires user-scoped resource membership state backed by company-scoped API and database contracts. > - The branch also needed to preserve HTTP worktree login sessions and keep the project list easier to scan after membership grouping. > - This pull request adds resource membership controls, sidebar leave actions, grouped/sortable project listings, and focused tests. > - The benefit is a cleaner personal workspace view without weakening company-scoped access to the underlying project or agent detail pages. ## What Changed - Added `project_memberships` and `agent_memberships` tables with API/shared/server contracts for current-user join/leave state. - Renumbered the membership migration to `0090_resource_memberships` after rebasing onto current `master`, and made it idempotent for anyone who had applied the old branch-local `0087` migration. - Added project and agent sidebar leave actions, plus list filtering that waits for membership state before hiding resources. - Added grouped project listing, project sorting controls, and reserved row subtitle height for cleaner scanning. - Fixed HTTP auth cookie security handling so HTTP worktree sessions can persist. - Updated focused server and UI tests for the new membership, sidebar, project list, and auth behavior. ## Verification - `pnpm exec vitest run server/src/__tests__/better-auth.test.ts server/src/__tests__/resource-memberships-routes.test.ts ui/src/pages/Projects.test.tsx ui/src/components/SidebarProjects.test.tsx ui/src/components/SidebarAgents.test.tsx ui/src/components/MembershipAction.test.tsx ui/src/components/EntityRow.test.tsx` - Confirmed the branch is rebased on current `origin/master`. - Confirmed the PR diff does not include `pnpm-lock.yaml` or `.github/workflows` changes. ## Risks - Migration safety: low to medium. The migration now uses `IF NOT EXISTS` / guarded constraints and is numbered after current master migrations, but it should still get CI coverage against fresh databases. - UI behavior: low. Left resources are hidden from sidebar only after membership state loads; direct detail access remains available. - Auth behavior: low. Cookie security is relaxed only for HTTP/private local-style origins where secure cookies would prevent login persistence. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex coding agent, tool-enabled shell/git workflow, context window not exposed by runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Screenshot note: no browser screenshots were captured in this heartbeat; the UI changes are covered by focused component tests above. --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-25 13:12:41 -05:00
Dotta	60efa38f86	docs: add v2026.525.0 release changelog (#6667) ... ## Summary - Adds `releases/v2026.525.0.md` for the upcoming stable release covering 32 commits since `v2026.517.0` (2026-05-17 → 2026-05-25). - Highlights: Modal sandbox provider plugin, first-party workspace diff viewer, routine env secrets, local Cloud Upstream sync, and ACPX-Claude adapter polish. - Categorized into Highlights / Improvements / Fixes with inline PR + contributor attribution per the release-changelog skill. ## Source range `v2026.517.0..origin/master` (ECE8A51E22 at time of cut). ## Verification - Manual scan of `git log v2026.517.0..HEAD --no-merges` and merged-PR titles since 2026-05-17. - Confirmed no `BREAKING CHANGE:` / `feat!:` markers in the range (no Breaking Changes / Upgrade Guide sections needed). - DB migrations in range (`0086_routine_env_runtime_contract`, `0087_backfill_environment_manage_human_defaults`, `0088_backfill_principal_access_compatibility`, `0089_cloud_upstreams`) are additive/backfill-only — none flagged as breaking. - Contributor list excludes Paperclip founders (cryppadotta, devinfoley) and bot accounts per skill rules. ## Test plan - [ ] Reviewer eyeballs the changelog against the recent PR list. - [ ] Reviewer confirms the highlight set is the right shipped subset. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-25 09:12:23 -07:00
Dotta	ece8a51e22	[codex] Bundle local branch fixes from PAP-10032 (#6604) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - This branch accumulated multiple already-tested control-plane, adapter runtime, invite, workspace, plugin, and UI quality fixes on the primary Paperclip checkout. > - `origin/master` advanced while those commits were still local, so the branch needed to be preserved and reconciled before review. > - Splitting the branch commit-by-commit against the new base produced overlapping conflicts with recently merged upstream PRs. > - This pull request keeps the remaining branch as one standalone PR because the final diff is 38 files after removing screenshot artifacts, under Greptile's 100-file cap, and can be merged independently after review. > - The benefit is that none of the local work is lost, the branch is now based on current `origin/master`, and reviewers can evaluate the reconciled changes in one place. ## What Changed - Merged the local accumulated branch with current `origin/master` and resolved the invite-flow overlaps from the newer upstream companies query helper. - Preserved the local fixes for invite existing-member behavior, invite link copy fallback, reusable workspace selection, worktree auth, static SPA fallback, markdown wrapping, plugin slot registration, cloud upstream UX/server polish, project sorting, and related tests. - Removed screenshot artifacts from the PR per review request. - Kept the PR under the requested file limit: 38 files changed, with no `pnpm-lock.yaml` or `.github/workflows/*` changes. ## Verification - `NODE_ENV=test pnpm exec vitest run ui/src/pages/CompanyInvites.test.tsx ui/src/pages/InviteLanding.test.tsx ui/src/pages/Projects.test.tsx ui/src/plugins/slots.test.ts ui/src/components/MarkdownBody.test.tsx server/src/__tests__/invite-accept-existing-member.test.ts server/src/__tests__/static-index-html.test.ts server/src/__tests__/execution-workspaces-service.test.ts server/src/__tests__/better-auth.test.ts server/src/__tests__/worktree-config.test.ts` - `NODE_ENV=test pnpm --filter @paperclipai/ui typecheck` - `NODE_ENV=test pnpm --filter @paperclipai/server typecheck` - Confirmed `git diff --name-only origin/master...HEAD | wc -l` is `38`. - Confirmed no PR diff entries match `pnpm-lock.yaml`, `.github/workflows/*`, or `screenshots/*`. ## Risks - Medium review risk because this is a bundled rescue PR rather than several narrow feature PRs. - Invite flow and company cache behavior overlapped with newer upstream changes; the merge resolution intentionally keeps the shared `companiesListQueryOptions` helper while preserving local existing-member invite behavior. - Visual review evidence is no longer attached in-repo because screenshots were removed from this PR per review request. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent, with repository tool access, terminal execution, and git/GitHub CLI operations. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] UI screenshots were intentionally removed from this PR per review request - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: CodexCoder <codexcoder@paperclip.local>	2026-05-25 07:25:26 -05:00
Devin Foley	96f0279e08	Make ACPX-Claude adapter work seamlessly (PAPA-388) (#6590) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, so when an adapter fails, the platform must surface enough detail for the next agent (or human reviewer) to act > - The `acpx_local` adapter wraps `claude-agent-acp`, which in turn drives the Claude Code SDK — three layers, three different permission and error-handling models > - A user created a `Claude Local ACPX` agent in PAPA-387 and it failed instantly with the generic `acpx.error / "Internal error"` log, stranding the work and triggering an opaque `stranded_assigned_issue` recovery to the CTO > - Once the diagnostic blackbox was opened, the underlying cause turned out to be two SDK-level mismatches: a model-name allowlist that rejects bare IDs like `claude-opus-4-7`, and a Claude Code permission/Read-sandbox configuration that silently denies every non-allowlisted tool when the user's `~/.claude/settings.json` has `defaultMode: "dontAsk"` > - This pull request fixes both classes of failure in the adapter itself so new ACPX agents work seamlessly without per-host configuration, and widens the diagnostic surface so the *next* failure of any kind is actionable > - The benefit is that ACPX-Claude can join the regular agent roster — verified end to end on PAPA-401, where the agent successfully reached the Paperclip API, opened a worktree, surveyed existing notification PRs, and posted a structured plan ## What Changed - Widen ACPX failure diagnostics (`packages/adapters/acpx-local/src/server/execute.ts`): - Capture `err.name`, ACP code, `cause.message`, retryable flag, and a 5-frame stack preview into `errorMeta`. - Promote phase-specific error codes: `ensure_session → acpx_session_init_failed`, `configure_session → acpx_session_config_failed`, `turn → acpx_turn_failed`, plus mapping for `ACP_BACKEND_MISSING` / `ACP_BACKEND_UNAVAILABLE`. - Set `verbose: true` on the ACPX runtime so its session-event log flows through `ctx.onLog`. - Capture child-process stderr via a wrapper-script tee into `<stateDir>/run-stderr/<runId>.log`, inline the tail into the `acpx.error` payload as `childStderrTail`, and forward it through `ctx.onLog("stderr", …)` so it lands in the heartbeat `stderrExcerpt` column (existing redaction applies). - Set the model via `ANTHROPIC_MODEL` env for the `claude` agent instead of `set_config_option(model, …)`. The ACP server's `set_config_option` handler validates against an internal allowlist and rejects bare IDs like `claude-opus-4-7`. `ANTHROPIC_MODEL` is read during initialization and bypasses that check. - Seed `<worktree>/.claude/settings.local.json` before spawning `claude-agent-acp` (the seamless-API fix). Since `claude-agent-acp` hard-codes `settingSources: ["user", "project", "local"]` and "local" has the highest precedence: - Set `permissions.defaultMode: "default"`, but **only** if the user's value is missing or `"dontAsk"` (the broken case). Other modes like `acceptEdits`/`plan` are preserved. - Pre-allow Paperclip's Bash surface (`Bash(curl:*)`, `Bash(env:*)`, `Bash(<cwd>/scripts/paperclip-issue-update.sh:*)`, `Bash(<cwd>/scripts/paperclip:*)`). - Widen `permissions.additionalDirectories` to include `stateDir`, `agentHome`, and the per-company instance root (`~/.paperclip/instances/<id>/companies/<companyId>`). Scoped to this company only — does not expose other tenants. - Existing user entries are merged, not replaced. The resolved roots are folded into the session fingerprint so warm-session handles invalidate when they change. - Sync the existing server-side integration test (`server/src/__tests__/acpx-local-execute.test.ts`) to assert `acpx_session_init_failed` instead of the now-removed `acpx_protocol_error` for `ACP_SESSION_INIT_FAILED` (a follow-up to commit 1). ## Verification - `pnpm --filter "@paperclipai/adapter-acpx-local" run typecheck` — passes. - `pnpm vitest run` in `packages/adapters/acpx-local` — 35/35 pass, includes 4 new tests covering the settings.local.json write path (claude only, merge with pre-existing content, `dontAsk` override, codex no-op). - `pnpm vitest run src/__tests__/acpx-local-execute.test.ts` in `server/` — 15/15 pass after the test-sync commit. - End-to-end manual verification (PAPA-401): the `Claude Local ACPX` agent that previously hit "restricted environment" now successfully reaches the Paperclip API, opens its worktree, posts structured plan comments, and flips the issue to `in_review` without any external configuration. ## Risks - **Low**, scoped to the `acpx_local` adapter. The settings.local.json write is per-worktree (worktrees live under `.paperclip/worktrees/<issue>/`) and only triggers when `acpxAgent === "claude"`. Existing user content is merged with `[...existing, ...paperclip]` and deduped — nothing is overwritten outright. - The `defaultMode` override is intentionally narrow: it only flips `"dontAsk"` (which silently denies every tool and is the root cause) to `"default"`. Users who explicitly picked `acceptEdits`, `plan`, or any other mode keep their choice. - Stderr capture goes through the existing `log-redaction` pass before persisting, so `PAPERCLIP_API_KEY` and similar secrets in the wrapper env don't leak into heartbeat logs. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - Claude Opus 4.7 (`claude-opus-4-7`), running in the `claude_local` adapter via Paperclip's harness. Extended thinking enabled, tool use enabled. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — N/A (adapter-only) - [ ] I have updated relevant documentation to reflect my changes — no user-facing docs changed; internal commentary in the code change explains the SDK constraints - [x] I have considered and documented any risks above - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-23 13:01:27 -07:00
Aron Prins	897cc322c7	Improve external agent invite flow (#6183) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Agent creation can happen through local runtimes, managed runtimes, and external agents that onboard through invites. > - The old OpenClaw-oriented invite UX lived under company settings/invites and made a gateway-specific path look like a company access setting. > - That hid the broader bring-your-own-agent flow and forced operators to leave the add-agent modal when adding an external agent. > - This pull request moves external agent invite generation into the add-agent modal and makes the copy agent-oriented instead of OpenClaw-only. > - The benefit is a clearer agent-first onboarding path while company invites stay focused on human access. ## What Changed - Added an external-agent invite branch to the add-agent modal, including a dedicated prompt result view with Back navigation. - Added a shared agent onboarding prompt builder and focused modal coverage for prompt replacement/back navigation. - Removed the agent invite prompt UI from Company Settings and Company Invites, leaving Company Invites focused on human access links and invite history. - Updated the hidden OpenClaw Gateway runtime hint to direct operators to the add-agent invite flow instead of presenting it as a blocked runtime card. - Updated invite/onboarding docs, storybook coverage, and server-side onboarding copy toward generic agent language while preserving existing gateway compatibility. ## Verification - `pnpm -r typecheck` - `pnpm build` - `FAKE_BIN="$(mktemp -d)/bin"; mkdir -p "$FAKE_BIN"; printf '#!/bin/sh\nexit 1\n' > "$FAKE_BIN/tailscale"; chmod +x "$FAKE_BIN/tailscale"; PATH="$FAKE_BIN:$PATH" pnpm test:run` - `pnpm test:run` without the fake `tailscale` shim was also attempted; it failed only in two pre-existing CLI tailnet fallback tests because this host has a real Tailscale address (`100.125.202.3`) where those tests expect no Tailscale. - Focused confirmation for that host-env issue: `FAKE_BIN=... PATH="$FAKE_BIN:$PATH" pnpm exec vitest run --project paperclipai cli/src/__tests__/network-bind.test.ts cli/src/__tests__/onboard.test.ts` - Manual UI verification: served UI locally in light mode, opened add-agent modal, generated external agent prompt, verified the generated prompt replaces the form and Back returns to the form. ### Screenshots    ## Risks - Existing OpenClaw gateway compatibility remains, but operators now discover external agent onboarding from the add-agent modal instead of company settings. - Agent invites still appear in the invite history table, so that page may show agent-scoped invite rows even though it no longer creates agent onboarding prompts. - Low migration risk: no schema changes. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent in Codex desktop; tool-enabled repository, shell, browser, and GitHub workflow. Context window size was not exposed by the runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-23 09:09:40 -05:00
Devin Foley	e3c875c1c7	fix(sandbox): prevent E2B workspace upload + lease idle failures (PAPA-382) (#6560) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Heartbeats run inside managed sandboxes (E2B, Cloudflare Sandbox), and each run begins by uploading the agent's workspace as a tar archive > - PAPA-381's E2B runs were failing at 5 and 11 minutes — two distinct failure modes were entangled: workspace tar extraction errors on Linux, and sandbox idle/lease timeouts during normal heartbeat gaps > - Workspace tar extraction failed because macOS bsdtar embeds `LIBARCHIVE.xattr.*` PAX headers that GNU tar on Linux rejects with "This does not look like a tar archive"; the existing `COPYFILE_DISABLE=1` only suppresses AppleDouble `._*` sidecars, not inline PAX xattr entries > - E2B sandboxes also expired between heartbeats because `timeoutMs` defaulted to a short window and was never refreshed per execute, and Cloudflare sandboxes idled out because `sleepAfter` defaulted to 10 minutes > - This pull request adds `--no-xattrs` to the workspace tar invocation, refreshes the E2B sandbox lifetime on each execute and bumps the default `timeoutMs` to 1h, and raises the Cloudflare `sleepAfter` default to 1h > - The benefit is that long-running heartbeat-driven runs (Claude, Codex, etc.) survive across both their initial workspace upload and the natural idle gaps between executes on both E2B and Cloudflare ## What Changed - `packages/adapter-utils/src/sandbox-managed-runtime.ts`: added `--no-xattrs` to `createTarballFromDirectory` so macOS bsdtar produces a clean POSIX tar that GNU tar on Linux can extract, with an inline comment explaining why `COPYFILE_DISABLE=1` alone is insufficient. - `packages/plugins/sandbox-providers/e2b/src/plugin.ts`: refresh the sandbox lifetime on every execute (so long runs don't expire mid-job) and raised the default `timeoutMs` to 1h. - `packages/plugins/sandbox-providers/e2b/src/manifest.ts` and `plugin.test.ts`: updated manifest defaults and added regression coverage for the new behavior. - `packages/plugins/sandbox-providers/cloudflare/src/config.ts`, `manifest.ts`, `plugin.test.ts`: raised default `sleepAfter` from 10m to 1h, mirroring the E2B 1h default, and added a regression test asserting the acquire-lease request body sends `sleepAfter: "1h"` when not overridden. ## Verification - `pnpm --filter @paperclipai/plugin-e2b test` - `pnpm --filter @paperclipai/plugin-cloudflare-sandbox test` - Locally cherry-picked the `--no-xattrs` fix onto master and confirmed end-to-end via a real PAPA-381-style heartbeat-driven E2B run that the workspace upload now extracts cleanly on Linux. The user (board operator) tested this on master and reported "Ok, that worked." - Manual reviewer steps: trigger an E2B heartbeat from a macOS host (this is where the bsdtar xattr headers come from), confirm the workspace tar extracts on the Linux sandbox side; run a long (>15 min) Cloudflare sandbox flow and confirm no lost-lease/idle errors between executes. ## Risks - Low risk overall. - `--no-xattrs` is widely supported by both macOS bsdtar and GNU tar (Linux). Worst case it silently no-ops on a future host that doesn't support it; in that case the existing failure mode reappears, it doesn't introduce a new one. - Raising default `timeoutMs` (E2B) and `sleepAfter` (Cloudflare) from short values to 1h means sandboxes stay alive longer between executes by default. This is the intended behavior — operators that want a tighter idle window can still override via plugin config. - E2B per-execute sandbox lifetime refresh adds a small API call per execute; it is bounded by the same client that already handles execute traffic, so no new dependencies or retry semantics. ## Model Used - Claude (Anthropic), `claude-opus-4-7`, extended thinking enabled, tool use enabled (file/grep/git tools and Paperclip control-plane API). Used to diagnose the dual failure mode (workspace tar PAX xattr headers + sandbox lifetime), write the fixes and tests, and drive the verification loop with the board operator. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots (N/A — no UI changes) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-22 13:34:11 -07:00
Aron Prins	e85ff094ec	fix(ui): invite page goes blank from companies query-key collision (#6433) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies; humans operate the board through the React UI. > - The board gates company access via `CompanyProvider` (CompanyContext) and onboards new humans through the invite landing page at `/invite/:token`. > - Reported symptom: opening an invite link and signing in works, but the page then renders completely blank (black in dark mode). > - End-to-end browser testing reproduced a client-side crash: `companiesQuery.data?.some is not a function` and `Cannot read properties of undefined (reading 'filter')`. > - Root cause: `CompanyProvider` and `InviteLandingPage` both use the React Query key `["companies"]` but return **different shapes** — `{ companies, unauthorized }` vs a bare `Company[]` — so they silently corrupt the shared cache entry; whichever component reads the other's shape calls `.some()`/`.filter()` on the wrong type and throws, unmounting the tree. > - Owners never hit it (they never mount the invite page); only invitees landing on `/invite/:token` crash. > - This PR unifies the `["companies"]` query into a single shared definition so the cache entry always has one shape and the two consumers can't drift apart again. > - The benefit is a working invite/onboarding flow and removal of a whole class of cache-shape bugs on this key. ## What Changed - Add `ui/src/api/companies-query.ts` exporting a single shared `companiesListQueryOptions` (and `CompanyListResult`) — one `queryKey` + one `queryFn` that always returns the wrapped `{ companies, unauthorized }` shape, documented with the shared-cache contract. - `ui/src/context/CompanyContext.tsx` now uses `useQuery(companiesListQueryOptions)` instead of an inline copy of that query. - `ui/src/pages/InviteLanding.tsx` uses the same `companiesListQueryOptions` (with its own `enabled` gate), reads `companiesQuery.data?.companies` for the membership checks, and uses `queryClient.fetchQuery(companiesListQueryOptions)` in the post-auth path — so it reads and writes the identical shape. ## Verification - `pnpm --filter @paperclipai/ui typecheck` — clean. - `vitest run src/pages/InviteLanding.test.tsx src/context/CompanyContext.test.tsx` — 17/17 pass, unchanged. - Manual end-to-end via a real browser against a LAN-exposed authenticated instance: - Owner creates an Owner-role invite. - New user opens the link and registers — **the "awaiting approval" screen renders** (previously blank), `POST /api/invites/:token/accept` returns `202`, no console errors. - Owner approves at Company Settings → Access (`200`); invitee becomes an active member. - Invitee signs in — full board loads; smoke test of dashboard / issues / inbox / routines / goals / company settings — all render, zero `pageerror`s. - Before: invite page `#root` empty after sign-in (blank/black). After: awaiting-approval panel renders. (Screenshots available on request.) ## Risks - Low. `CompanyProvider`'s query behavior is unchanged (same `queryFn` logic, just extracted into a shared module). `InviteLandingPage` now reads the same shape it writes. No API, schema, or migration changes. Existing tests pass unchanged. ## Model Used - Claude (Anthropic), model ID `claude-opus-4-7` (Opus 4.7), 1M-context, extended thinking + tool use; driving Claude Code with browser automation for end-to-end reproduction and verification. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [ ] I have added or updated tests where applicable (existing InviteLanding/CompanyContext tests cover the touched code and pass; a cross-provider regression test that mounts both consumers is a sensible follow-up) - [ ] If this change affects the UI, I have included before/after screenshots (described textually above; this is a crash/blank-page fix, screenshots available on request) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 15:28:49 -05:00
Aron Prins	4811d8dd33	Fix wrapped company issue prefix conflicts (#6423) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Company creation is the first control-plane object operators create, and the generated issue prefix becomes part of task identity. > - The company service already retries when a generated issue prefix collides with the `companies_issue_prefix_idx` unique constraint. > - Drizzle 0.45.x wraps PostgreSQL errors in `DrizzleQueryError`, leaving the real `23505` constraint error on the `.cause` chain. > - The existing retry detector only inspected the top-level error, so wrapped prefix collisions surfaced as 500s instead of retrying. > - This pull request walks the error cause chain for the exact prefix constraint and verifies the retry path against embedded Postgres. > - The benefit is company creation no longer fails when generated prefixes collide under Drizzle 0.45.x wrappers. ## What Changed - Walk the error `.cause` chain when detecting `companies_issue_prefix_idx` unique violations, with a cycle guard and support for `constraint` / `constraint_name` fields. - Added an embedded Postgres regression test that seeds `ARO`, creates `Aron & Sharon`, and verifies the retry produces `AROA`. - Stabilized existing async tests touched by full verification: instance sidebar plugin rendering now waits for React Query results, and Tailscale-unavailable CLI tests explicitly hide host `tailscale` detection. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/companies-service.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/heartbeat-stale-queue-invalidation.test.ts` - `pnpm --filter @paperclipai/ui exec vitest run src/components/InstanceSidebar.test.tsx` - `pnpm --filter paperclipai exec vitest run src/__tests__/network-bind.test.ts src/__tests__/onboard.test.ts` - `pnpm test:run` - `pnpm -r typecheck` - `pnpm build` ## Risks - Low runtime risk: the retry behavior only expands detection for the existing exact company issue-prefix unique constraint. - The cause-chain walk is bounded by visited objects to avoid cycles. - The sidebar and CLI changes are test-only stabilization and do not change production 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 coding agent in Codex desktop, with local shell/tool execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots (N/A: no UI behavior change) - [x] I have updated relevant documentation to reflect my changes (N/A: bug fix with no user-facing docs change) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Closes #6350	2026-05-22 15:27:54 -05:00
Dotta	90117827eb	[codex] Polish board UI mobile flows (#6550) ... ## Thinking Path > - Paperclip is the board UI and control plane for supervising AI-agent companies. > - Operators repeatedly use mobile navigation, issue creation, inbox scanning, and markdown reading surfaces. > - Small layout and interaction rough edges add friction to those high-frequency workflows. > - The branch included a set of related board UI polish changes that were too small to review as many separate PRs. > - This pull request groups the remaining mobile/navigation/markdown polish into one standalone branch. > - The benefit is smoother board operation without mixing in unrelated backend feature work. ## What Changed - Tightened company settings navigation behavior on mobile. - Fixed mobile new issue dialog height and moved issue priority into the overflow controls on small screens. - Restored browser controls for home-screen app mode. - Fixed plugin-route sidebar selection on nested page loads. - Added markdown preformatted-block wrapping controls and coverage. - Kept updated issue list pages sorted by updated time in the board UI. ## Verification - `pnpm --filter @paperclipai/plugin-sdk build` - `NODE_ENV=test pnpm exec vitest run ui/src/components/Layout.test.tsx ui/src/components/MarkdownBody.test.tsx ui/src/components/MarkdownBody.wrap.test.tsx ui/src/components/NewIssueDialog.test.tsx ui/src/components/access/CompanySettingsNav.test.tsx ui/src/lib/pwa-install-mode.test.ts ui/src/pages/Inbox.test.tsx` The targeted UI tests passed. React emitted existing act-wrapping warnings in a few test files, but there were no test failures. ## Risks - Medium-low: changes span several UI surfaces, but they are mostly layout/interaction polish with targeted component tests. - Visual screenshots are not newly captured in this split PR; follow-up review should include browser/visual QA before marking ready. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via `codex_local`, tool-enabled coding session; exact context window not exposed by this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-22 10:13:47 -05:00
Dotta	ad6effa65c	[codex] Improve runtime and import reliability (#6549) ... ## Thinking Path > - Paperclip coordinates autonomous company work through local and hosted runtime surfaces. > - Local embedded Postgres and tenant import/export paths are foundational reliability pieces. > - A runtime failure in either path can stop agents or imports before useful work begins. > - The branch included remaining fixes for embedded native library bootstrap and async tenant import handling. > - This pull request groups those runtime/import reliability changes into one standalone PR. > - The benefit is a more robust local runtime and safer cloud tenant import behavior. ## What Changed - Prepared embedded Postgres native runtime before startup in CLI/server/test entrypoints. - Added embedded Postgres native bootstrap coverage. - Added async tenant import job handling and deferred validation coverage. - Kept the runtime/import changes based directly on current `origin/master` after related upstream PRs had already merged. ## Verification - `pnpm --filter @paperclipai/plugin-sdk build` - `NODE_ENV=test pnpm exec vitest run packages/db/src/embedded-postgres-native.test.ts server/src/__tests__/company-portability-routes.test.ts` ## Risks - Medium-low: this touches startup/import paths, but the branch is small and covered by targeted tests. - The embedded Postgres change depends on platform-specific native-library behavior, so CI and follow-up checks should still verify supported runners. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via `codex_local`, tool-enabled coding session; exact context window not exposed by this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-22 09:57:22 -05:00
Dotta	e43b392a79	[codex] Add local Cloud Upstream sync (#6548) ... ## Thinking Path > - Paperclip is the control plane for AI-agent companies. > - Operators need a path to move local company state toward Paperclip Cloud without losing local-first control. > - The Cloud Upstream flow needs API, persistence, CLI, and board UI surfaces that agree on the same manifest/run model. > - The existing branch had the feature work plus UX and error-handling follow-ups. > - This pull request packages the remaining Cloud Upstream sync work into one standalone branch. > - The benefit is an inspectable local-to-cloud sync workflow with preview, conflicts, activation, and captured UX review states. ## What Changed - Added Cloud Upstream shared types, server routes/services, and persisted run schema/migration. - Added Paperclip Cloud CLI sync helpers and local connection storage. - Added the Cloud Upstream board UI, settings entry points, query keys, and UX lab page. - Added preview/activation checklist behavior, redirect handling, manifest-only preview support, friendly errors, in-flight hints, and entity count summaries. ## Verification - `pnpm --filter @paperclipai/plugin-sdk build` - `NODE_ENV=test pnpm exec vitest run cli/src/__tests__/cloud.test.ts server/src/__tests__/instance-settings-routes.test.ts server/src/__tests__/instance-settings-service.test.ts ui/src/pages/CloudUpstream.test.tsx ui/src/components/CompanySettingsSidebar.test.tsx` - `NODE_ENV=test pnpm exec vitest run server/src/__tests__/cloud-upstreams.test.ts` Worktree setup note: the isolated worktree install skipped native sqlite build scripts, so I copied the already-built local sqlite binding from the main checkout before running `server/src/__tests__/cloud-upstreams.test.ts`. The test then passed. ## Risks - Medium: this adds a database migration and a broad feature path across CLI/server/UI. - Merge order: this is the only PR in this split with a DB migration; merge it before any future Cloud Upstream migration follow-up. - Mitigation: the PR is based directly on current `origin/master`, has targeted route/service/UI tests, and keeps the feature behind existing experimental Cloud Sync settings. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via `codex_local`, tool-enabled coding session; exact context window not exposed by this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, screenshot artifacts are intentionally omitted per reviewer request - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-22 09:56:22 -05:00
Dotta	a1835cfa5e	[codex] Harden plugin runtime invocation scope (#6547) ... ## Thinking Path > - Paperclip orchestrates AI-agent companies through a company-scoped control plane. > - Plugins extend that control plane, but plugin workers still call back into host APIs. > - Those worker-to-host calls need the same company boundary guarantees as normal API routes. > - Plugin action handlers also need authenticated actor context from the host instead of trusting caller-supplied params. > - This pull request hardens plugin bridge/action scope and keeps plugin operation issues out of normal issue surfaces. > - The benefit is safer plugin execution with clearer authorization boundaries and better test coverage. ## What Changed - Added host-owned invocation context plumbing for nested plugin worker calls. - Added actor context to plugin `performAction` calls and test harness helpers. - Enforced company invocation scope on worker-to-host calls and filtered company lists to the active invocation scope. - Extended plugin action route tests for board and agent actor context, spoofed company params, and cross-company rejection. - Extended plugin worker manager coverage for invocation-scope propagation. - Filtered typed and legacy plugin operation issue origins from default issue/inbox lists. ## Verification - `pnpm --filter @paperclipai/plugin-sdk build` - `NODE_ENV=test pnpm exec vitest run packages/plugins/sdk/tests/host-client-factory.test.ts packages/plugins/sdk/tests/testing-actions.test.ts server/src/__tests__/plugin-routes-authz.test.ts server/src/__tests__/plugin-worker-manager.test.ts server/src/__tests__/issues-service.test.ts` Note: embedded Postgres issue-service tests reported host-level Postgres init skip for 47 tests; the non-embedded targeted tests passed. ## Risks - Medium: plugin host authorization paths are sensitive, and external plugins may rely on previously loose company params. - Mitigation: the change only tightens calls when the host attached a company invocation scope and includes explicit tests for board, agent, and nested worker calls. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI GPT-5 Codex via `codex_local`, tool-enabled coding session; exact context window not exposed by this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-22 09:16:24 -05:00
Dotta	38c185fb8b	[codex] Add agent permissions and controls plan (#6386) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies by keeping task ownership, approvals, and operator control inside one control plane. > - Agent permissions and plugin-hosted company settings sit on the boundary between autonomy and governance. > - V1 needs scoped task assignment rules, plugin extension points, and clearer company access surfaces without weakening company boundaries. > - The branch builds the core authorization service, plugin SDK/host APIs, and UI simplifications needed to support those controls. > - Paperclip EE plugin surfaces were intentionally moved out of this core PR per review direction, so this PR now carries only the public core/plugin infrastructure work. > - The latest updates preserve the PAP-9937 branch changes that belong in this PR, remove the `design/` artifacts, and exclude the experimental `plugin-briefs` package. > - Greptile feedback was applied through the authorization/audit paths and the final cleanup commit was re-reviewed at 5/5 with no unresolved Greptile threads. > - The benefit is safer assignment control with extension hooks for richer permission products while preserving simple defaults for normal operators. ## What Changed - Added scoped task-assignment authorization decisions and routed issue/agent assignment mutations through the authorization service. - Added plugin SDK and host APIs for company settings slots, authorization policy/grant management, assignment previews, and bridge invocation scope propagation. - Simplified core company access UI and moved advanced controls behind plugin-provided settings surfaces. - Added retry-now affordances for blocked issue next-step notices. - Added protected-assignment enforcement for persisted agent/project/issue policies, including explicit-grant fallback behavior. - Added incremental principal-access compatibility backfill for active agent memberships and role-default human permission grants. - Added the Markdown code block wrap action fix from the latest branch changes. - Removed `design/` artifacts from the PR and removed `packages/plugins/plugin-briefs` from the final diff. - Addressed Greptile feedback for plugin actor sanitization, legacy membership handling, audit pagination, unknown grant-scope metadata, and startup test mocks. ## Verification - `pnpm exec vitest run server/src/__tests__/access-service.test.ts server/src/__tests__/company-portability.test.ts` -> 2 files passed, 54 tests passed. - `pnpm exec vitest run server/src/__tests__/server-startup-feedback-export.test.ts server/src/__tests__/access-service.test.ts server/src/__tests__/company-portability.test.ts` -> 3 files passed, 62 tests passed. - `pnpm exec vitest run server/src/__tests__/authorization-service.test.ts server/src/__tests__/plugin-access-authorization-host-services.test.ts server/src/__tests__/server-startup-feedback-export.test.ts` -> 3 files passed, 28 tests passed. - `pnpm --filter @paperclipai/server typecheck` -> passed. - `git diff --check` -> passed. - `node ./scripts/check-docker-deps-stage.mjs` -> passed. - `CI=true pnpm install --frozen-lockfile --ignore-scripts` -> passed with no lockfile update. - `pnpm exec vitest run ui/src/components/MarkdownBody.interaction.test.tsx` -> 1 test passed. - `git ls-files design packages/plugins/plugin-briefs | wc -l` -> 0. - GitHub CI on `40cd83b53` -> all checks passed, merge state `CLEAN`. - Greptile on `40cd83b53` -> 5/5, 102 files reviewed, 0 comments/annotations added, 0 unresolved review threads. - Confirmed the PR diff contains no `design/`, `packages/plugins/plugin-briefs`, `pnpm-lock.yaml`, or `.github/workflows` changes. ## Risks - Medium: task assignment authorization paths are behaviorally stricter for protected/private policy data, so existing plugin-authored policies may block assignment until explicit grants or approval flows are configured. - Medium: plugin-host authorization APIs expand the surface area available to trusted plugins and need careful review for company scoping. - Low: startup now performs a principal-access compatibility backfill, but the migration and runtime backfill use conflict-tolerant inserts. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent, tool-enabled workflow with shell, git, and GitHub CLI access. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-22 08:12:52 -05:00
Dotta	c91a062326	[codex] Runtime control-plane fixes (#6380) ... ## Thinking Path > - Paperclip orchestrates AI agents through a server-side control plane > - That control plane depends on reliable issue state transitions, plugin lifecycle behavior, import limits, and startup/shutdown handling > - Several small runtime fixes had accumulated on the working branch and were mixed with larger feature work > - Keeping them separate makes the correctness fixes reviewable and mergeable without waiting for cloud-sync UI work > - This pull request groups the server/runtime control-plane fixes into one standalone branch > - The benefit is a tighter, safer runtime baseline for retries, imports, plugin migrations, feedback flushing, and trusted cloud import handling ## What Changed - Fixed updated issue list pagination sorting and scheduled retry comment handling. - Re-applied pending plugin migrations during hot reload and fixed plugin-schema worktree seed restore. - Hardened public tenant DB startup, portable import body limits, trusted cloud import errors, and trusted cloud tenant import mutation access. - Expired stale request confirmations after user comments. - Added feedback export shutdown hardening so database-unavailable flush loops stop cleanly. - Guarded plugin worker `error` event emission when no listener is registered. ## Verification - `pnpm install --frozen-lockfile --ignore-scripts` - `pnpm --filter @paperclipai/plugin-sdk build` - `npm run install --prefix node_modules/.pnpm/sqlite3@5.1.7/node_modules/sqlite3` - `pnpm exec vitest run server/src/__tests__/issues-service.test.ts server/src/__tests__/plugin-lifecycle-restart.test.ts server/src/__tests__/server-startup-feedback-export.test.ts server/src/__tests__/issue-comment-reopen-routes.test.ts server/src/__tests__/issue-thread-interactions-service.test.ts server/src/__tests__/issue-thread-interaction-routes.test.ts server/src/__tests__/body-limits.test.ts server/src/__tests__/feedback-flush-controller.test.ts server/src/__tests__/error-handler.test.ts server/src/__tests__/board-mutation-guard.test.ts packages/db/src/backup-lib.test.ts` initially exposed local setup issues and two 5s test timeouts. - Rerun after local prereq build: `pnpm exec vitest run --testTimeout 15000 server/src/__tests__/issue-comment-reopen-routes.test.ts server/src/__tests__/issue-thread-interaction-routes.test.ts server/src/__tests__/feedback-flush-controller.test.ts server/src/__tests__/server-startup-feedback-export.test.ts` passed. - Some embedded Postgres-backed tests skipped on this host because local Postgres init was unavailable. ## Risks - Runtime-touching branch: startup/shutdown and issue interaction behavior should be reviewed carefully. - The feedback export change disables repeated flush attempts only for database connection-refused failures; other upload failures still log normally. - The plugin worker error guard avoids process crashes from unhandled EventEmitter errors but may hide errors from code paths that expected an emitted listener. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent with local shell/git/tool use. Exact hosted model ID and context-window size are not exposed by the local Paperclip adapter runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-20 10:37:11 -05:00
Dotta	f257530537	[codex] UI and dev ops quality-of-life (#6384) ... ## Thinking Path > - Paperclip operators spend most of their time scanning the board, inbox, sidebar, and local dev status surfaces > - Small UI and dev-ops frictions make repeated operator workflows feel slower than they need to be > - The working branch contained several independent quality-of-life improvements mixed with larger cloud work > - Grouping these smaller UI/dev-ops changes together keeps review overhead reasonable without merging them into feature PRs > - This pull request collects the operator-facing QoL polish into one standalone branch > - The benefit is a cleaner board navigation and local dev recovery experience without depending on cloud upstream sync ## What Changed - Relaxed forced 44px touch targets for small inline widgets. - Fixed mobile mention menu scrolling and sidebar spacing on touch/mobile layouts. - Synced inbox hover state with j/k selection. - Moved plugin sidebar entries into the Work section. - Added manual dev-server restart action/banner behavior. - Logged plugin bridge 502 causes for better diagnosis. ## Verification - `pnpm install --frozen-lockfile --ignore-scripts` - `pnpm --filter @paperclipai/plugin-sdk build` - `pnpm exec vitest run ui/src/components/MarkdownEditor.test.tsx ui/src/components/Sidebar.test.tsx ui/src/components/SidebarProjects.test.tsx ui/src/pages/Inbox.test.tsx ui/src/components/DevRestartBanner.test.tsx server/src/__tests__/dev-server-status.test.ts server/src/__tests__/health-dev-server-token.test.ts server/src/__tests__/plugin-routes-authz.test.ts` initially failed only because plugin SDK `dist` was not built in the fresh worktree. - Rerun after build: `pnpm exec vitest run server/src/__tests__/plugin-routes-authz.test.ts` passed. - The remaining targeted UI/dev-server tests passed on the first post-install run. ## Visual Evidence - Sidebar layout and plugin Work section:  - Inbox/task row selection and hover-state surface:  - Dev restart banner desktop:  - Dev restart banner mobile:  ## Risks - Mostly UI/dev ergonomics with low data risk. - Sidebar and inbox changes touch frequently used navigation surfaces, so visual review on desktop/mobile is still useful. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent with local shell/git/tool use. Exact hosted model ID and context-window size are not exposed by the local Paperclip adapter runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-19 15:52:39 -05:00
Dotta	43c5bb81b6	[codex] Workspace diff polish (#6383) ... ## Thinking Path > - Paperclip gives operators a workspace diff plugin so they can inspect agent changes before review > - The diff view needs reliable base-ref defaults and controls that stay usable while scrolling large diffs > - The working branch mixed those plugin improvements with unrelated server and cloud work > - Keeping the workspace diff plugin changes isolated makes them easy to test and review > - This pull request polishes the workspace diff plugin controls, base-ref behavior, and sticky headers > - The benefit is a more predictable diff review surface for agent workspaces ## What Changed - Fixed workspace diff default base-ref resolution. - Improved split/unified and working-tree/against-ref pane controls. - Made workspace diff headers stay sticky while scrolling. - Added a review screenshot at `screenshots/PAP-9841-workspace-diff.png`. ## Verification - `pnpm install --frozen-lockfile --ignore-scripts` - `pnpm --filter @paperclipai/plugin-sdk build` - `pnpm --filter @paperclipai/plugin-workspace-diff exec vitest run tests/plugin.spec.ts` - Result: 9 tests passed. ## Risks - UI-only plugin branch with low data risk. - The default base-ref inference should be reviewed against unusual worktree/upstream combinations. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent with local shell/git/tool use. Exact hosted model ID and context-window size are not exposed by the local Paperclip adapter runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-19 15:51:13 -05:00
Dotta	d67347be77	[codex] Provider vault secrets UX (#6381) ... ## Thinking Path > - Paperclip orchestrates AI agents that need scoped, auditable access to secrets > - Hosted and external deployments need provider vault configuration without exposing secret values in Paperclip metadata > - AWS Secrets Manager vault setup previously required too much manual operator knowledge > - Provider vault discovery and removal belong together as an independent secrets-management improvement > - This pull request adds AWS provider vault discovery/prefill plus vault removal flows > - The benefit is a safer operator path for configuring external secret storage before higher-level cloud workflows depend on it ## What Changed - Added shared validators/types for AWS provider vault discovery payloads and safe provider metadata. - Implemented AWS provider vault discovery preview on the server. - Added provider vault removal service/route behavior. - Added Secrets page UI for discovery prefill, removal messaging, and related rendering coverage. - Added Storybook provider-vault fixtures and captured screenshots for the new UX states. ## Verification - `pnpm install --frozen-lockfile --ignore-scripts` - `pnpm exec vitest run packages/shared/src/validators/secret.test.ts server/src/__tests__/aws-secrets-manager-provider.test.ts server/src/__tests__/secrets-routes.test.ts server/src/__tests__/secrets-service.test.ts ui/src/pages/Secrets.render.test.tsx` - Result: 4 files passed, 1 embedded Postgres-backed file skipped on this host because local Postgres init was unavailable. - `pnpm --filter @paperclipai/ui exec vitest run src/pages/Secrets.render.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` - Storybook screenshot capture against `Product/Secrets` on `http://127.0.0.1:60381/iframe.html?id=product-secrets--secrets-inventory&viewMode=story&globals=theme:dark` ## Screenshots Provider vaults tab after this change:  AWS discovery candidate flow:  Provider vault removal confirmation:  ## Risks - Secret provider metadata handling must remain non-sensitive; validators reject credential-bearing Vault URLs and sensitive AWS discovery keys. - AWS discovery depends on deployment credentials being configured correctly outside Paperclip-managed company secrets. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent with local shell/git/tool use. Exact hosted model ID and context-window size are not exposed by the local Paperclip adapter runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-19 15:50:23 -05:00
Dotta	9c29394f4d	[codex] Allow cloud tenant import mutations without browser origin (#6378) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Paperclip Cloud imports local company data into tenant Paperclip stacks through trusted server-to-server calls. > - Tenant imports authenticate as board actors with `source: "cloud_tenant"` because they act on behalf of an authorized stack user. > - The board mutation guard correctly protects browser session mutations with trusted `Origin`/`Referer` checks. > - But the guard treated trusted Cloud tenant calls like browser session mutations, so server-to-server imports without a browser origin failed with `403 Board mutation requires trusted browser origin`. > - This pull request exempts trusted Cloud tenant actors from browser-origin enforcement while preserving the session-backed browser guard. > - The benefit is that authorized Cloud imports can persist into tenant Paperclip storage without weakening browser CSRF protections. ## What Changed - Allow `req.actor.source === "cloud_tenant"` through `boardMutationGuard` without requiring browser `Origin` or `Referer` headers. - Add a focused regression test for Cloud tenant POST mutations without an origin. - Preserve the existing session-backed rejection test for board mutations that lack a trusted browser origin. ## Verification - `pnpm exec vitest run server/src/__tests__/board-mutation-guard.test.ts` - Result: 10 tests passed. ## Risks - Low risk: this only expands the existing non-browser exemption list to trusted Cloud tenant actors that have already passed tenant-server-token authentication. - The browser-session path remains covered by the existing rejection test, so missing-origin browser mutations still fail. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent, tool-enabled local repository editing and shell verification. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-19 14:25:58 -05:00
Dotta	bfe6369ef5	Guard cheap recovery model usage (#6371) ... ## Thinking Path > - Paperclip is the control plane that coordinates AI-agent work through issues, heartbeats, comments, approvals, and auditable recovery paths. > - The affected subsystem is heartbeat/recovery orchestration, especially the optional cheap model profile used for operational recovery overhead. > - Cheap recovery should repair status and liveness, but it must not become the worker lane that writes deliverables, continues source work, or propagates cheap execution hints into downstream retries. > - The gap was that cheap-profile hints could follow recovery wake contexts and assignment overrides farther than intended, making real work eligible to run on the cheap model. > - This pull request separates status-only cheap recovery from normal source-work continuations, adds route guards for deliverable mutations during cheap status-only runs, and documents the invariant. > - The benefit is safer retry/recovery behavior: cheap runs can clean up control-plane state, while any remaining source work resumes through a normal/original model path. ## What Changed - Added recovery model-profile work classes so status-only recovery carries explicit guard context and normal-model continuations scrub cheap hints. - Updated heartbeat, productivity review, liveness continuation, and recovery service wakeups to request cheap only for bounded status-only recovery work. - Blocked cheap status-only recovery runs from writing issue documents, plans, attachments, work products, or assigning downstream work back to `modelProfile: "cheap"`. - Added/updated server tests for cheap profile propagation, artifact/document guards, route authorization, retry scheduling, and successful-run handoff behavior. - Documented the recovery model-profile lane in `doc/SPEC-implementation.md` and `doc/execution-semantics.md`. - After rebasing onto current `public-gh/master`, stabilized the new `InstanceSidebar` plugin-filter tests so the PR check lane stays green. ## Verification - Local: `pnpm exec vitest run --config vitest.config.ts src/services/recovery/model-profile-hint.test.ts src/__tests__/issue-agent-mutation-ownership-routes.test.ts src/__tests__/issue-document-restore-routes.test.ts` from `server/` - 3 files, 37 tests passed after final edits. - Local: `pnpm exec vitest run --config vitest.config.ts src/__tests__/heartbeat-process-recovery.test.ts` from `server/` - 44 tests passed after rerunning the cleanup-sensitive file alone. - Local: `pnpm --filter @paperclipai/ui exec vitest run src/components/InstanceSidebar.test.tsx` - 4 tests passed. - Local: `pnpm --filter @paperclipai/server typecheck` - passed. - Local: `pnpm --filter @paperclipai/ui typecheck` - passed. - PR checks on latest head `6f8c3b1380f5bd872c6f49f6f7188ecf3bb6d263` - all green, including `verify`, build, typecheck, server/general/serialized tests, e2e, Snyk, and policy. - Greptile: pass 3 returned Confidence Score 5/5 with zero unresolved Greptile review threads. ## Risks - Medium risk: recovery behavior is intentionally stricter, so any path that incorrectly relies on cheap recovery to keep doing source work will now need to hand back to a normal-model run. - Low migration risk: no schema changes. - No product UI changes; the UI file touched is a test-only stabilization after rebasing onto current `master`. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex coding agent, GPT-5 model family (`gpt-5`), tool use and local code execution enabled; context window not exposed in this environment. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots (N/A: no product UI changes) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-19 13:46:02 -05:00
Devin Foley	24748de421	fix(ui): hide sandbox-provider plugins from Instance Settings sidebar (#6341) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Plugins extend Paperclip with new capabilities; the Instance Settings sidebar exposes per-plugin settings pages under a "Plugins" group > - Some plugins contribute only sandbox-provider drivers (E2B, exe.dev, Modal). They have no per-plugin settings UI — `PluginSettings` already redirects sandbox-provider-only plugins to the Environments page > - As a result, listing them as their own sidebar rows produced confusing entries that visually nested below the "Adapters" group and only lead to a stub redirect — there was no value to the user > - This pull request hides sandbox-provider-only plugins from the Instance Settings sidebar, and reorders the indented plugin list so it sits directly under the "Plugins" group it actually belongs to > - The benefit is a cleaner sidebar that only surfaces plugins with real per-plugin settings, and removes the visual mis-nesting under Adapters ## What Changed - `ui/src/components/InstanceSidebar.tsx`: filter out plugins whose only contribution is `sandboxProviders` (hybrid plugins that contribute sandbox providers *plus* something else still get a sidebar entry). Move the indented plugin list so it renders between the "Plugins" row and the "Adapters" row instead of after Adapters. - `ui/src/components/InstanceSidebar.test.tsx`: new test file with 4 cases — sandbox-only plugins hidden, hybrid plugins shown, ordering (plugin list appears under Plugins and before Adapters), and the existing non-plugin sidebar items still render. ## Verification - `pnpm -C ui vitest run src/components/InstanceSidebar.test.tsx` → 4/4 pass. - `pnpm typecheck` clean on the changed files. - Manual: visit `/instance/settings/plugins` — "E2B Sandbox Provider" and "exe.dev Sandbox Provider" rows no longer appear in the sidebar; remaining plugins are listed directly under the "Plugins" group, not below Adapters. **Before:** see the screenshot embedded in the linked issue (`PAPA-375`) — sandbox-provider plugins show as sidebar rows visually nested under "Adapters". **After:** sandbox-provider-only rows are gone; plugin list sits directly under the "Plugins" group. (A live runtime screenshot was not captured for this PR because the local server requires an authenticated browser session not currently available to the agent — happy to add one on request.) ## Risks - Low risk. Pure UI filter + reorder, scoped to `InstanceSidebar.tsx`. No backend or plugin-loader changes. Hybrid plugins that legitimately need a settings entry are explicitly preserved by the filter. Covered by 4 new unit tests. ## Model Used - Claude Opus 4.7 (`claude-opus-4-7`), Anthropic, via Claude Code in a Paperclip heartbeat. Standard tool-use mode (no extended thinking). 200K context. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — before is in the linked issue; after pending live capture (see Verification) - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Closes PAPA-375. Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-19 09:06:24 -07:00
Devin Foley	c0c5a8263d	feat(ui): wire SecretBindingPicker into JsonSchemaForm secret-ref fields (#6339) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Plugin authors expose configuration via JSON schemas, including secret fields marked `format: "secret-ref"` > - At the same time, Paperclip already has a first-class secrets store, and `SecretBindingPicker` is the canonical UI for binding to one of those stored secrets > - But `JsonSchemaForm`'s `SecretField` rendered only a plain password input, so configuring an E2B (or Modal / Cloudflare / Daytona) sandbox required leaving the form, copying a secret UUID, and pasting it back > - This pull request wires `SecretBindingPicker` into `SecretField` so every plugin secret-ref field gets the picker plus an optional raw-value fallback > - The benefit is that secret reuse becomes one click instead of a tab switch, and the raw-paste path still works for one-off keys or long SSH-style secrets ## What Changed - `ui/src/components/JsonSchemaForm.tsx` `SecretField` now renders `SecretBindingPicker` above the existing password/textarea input. UUID-shaped values are treated as bound refs (no raw input shown). Non-UUID values keep the password/textarea visible (auto-opened) for SSH keys and other long secrets. Empty fields show the picker plus a small "Or paste a raw value" toggle. - Selecting a secret writes the secret UUID to the form value — the server-side resolution in `server/src/services/environment-config.ts` (`resolveConfigSecretRefsForRuntime` / `collectEnvironmentSecretRefs`) is unchanged. The version selector on the picker is suppressed (`allowVersionSelector={false}`) because plugin secret refs always resolve at `"latest"`. - `ui/src/components/JsonSchemaForm.test.tsx` mocks the picker (which requires `CompanyContext` + `QueryClient` providers) and adds coverage for: picker render, UUID-bound state hides the raw input, picker selection writes the UUID through `onChange`, raw text keeps the password fallback. The original multiline (SSH key) case still asserts a textarea + no password input. ## Verification - `pnpm --filter @paperclipai/ui test src/components/JsonSchemaForm.test.tsx` → 4/4 passing - `pnpm --filter @paperclipai/ui test src/pages/PluginSettings.test.tsx` → 5/5 passing (existing consumer of `JsonSchemaForm`) - `pnpm --filter @paperclipai/ui exec tsc --noEmit` → clean - Manual: in the company Environments page, edit an environment with a sandbox driver that exposes a `secret-ref` field (e.g., E2B `apiKey`). The field should render the secret dropdown above the raw-value toggle; selecting an active secret persists its UUID, and saving the form continues to resolve the secret at runtime. Before/after screenshots: deferred — change was validated by [@devinfoley](https://github.com/devinfoley) on the main Paperclip instance before this PR was opened. Happy to add screenshots if a reviewer wants them. ## Risks - Low risk. The change is additive in the SecretField: the raw-value password/textarea path is preserved and auto-opens whenever the stored value is not a UUID, so existing SSH-key entries and unsaved raw values are untouched. - The new heuristic is "if `value` is a UUID, treat it as a bound secret". A user who somehow pasted a UUID as a literal value (not as a secret ref) would now see it rendered as a bound (possibly missing) secret in the picker. The previous UI already treated UUID values as opaque secret refs at save time (server converts UUIDs straight through), so the runtime behavior is unchanged. - Picker pulls company secrets via the existing `secretsApi.list` query. No new endpoints, no migrations. ## Model Used - Provider: Anthropic - Model: Claude Opus 4.7 (`claude-opus-4-7`) - Capabilities: tool use, extended reasoning - Surfaced through: Claude Code via Paperclip heartbeat (issue PAPA-377) ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots — deferred; user validated locally before opening the PR. Will add if requested. - [x] I have updated relevant documentation to reflect my changes (no docs needed — internal behavior of an existing form field) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 21:17:41 -07:00
Devin Foley	f343bae119	fix(ci): copy link-plugin-dev-sdk.mjs into Docker deps stage (#6338) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Releases ship via a Docker image built in the `build-and-push` CI workflow > - A recent change added `plugin-workspace-diff` to the pnpm workspace; its `postinstall` hook calls `scripts/link-plugin-dev-sdk.mjs` > - The Dockerfile's `deps` stage runs `pnpm install` before the full repo is copied, so the script was missing and `pnpm install` failed with `Cannot find module` > - Sandbox-provider plugins have the same hook but are excluded from the pnpm workspace, so they were unaffected — this was specific to `plugin-workspace-diff` > - This pull request copies `scripts/link-plugin-dev-sdk.mjs` into the `deps` stage alongside the package.json files > - The benefit is restoring the `build-and-push` CI workflow with a minimal one-line change ## What Changed - Add `COPY scripts/link-plugin-dev-sdk.mjs scripts/` to the Dockerfile's `deps` stage so the `plugin-workspace-diff` postinstall hook succeeds during `pnpm install`. ## Verification - Reproduces the original failure on `master` by running `docker build --target deps .` — fails at `pnpm install` with `Cannot find module '/app/scripts/link-plugin-dev-sdk.mjs'`. - With this patch, `docker build --target deps .` completes successfully through the `deps` stage. - CI `build-and-push` job (previously failing on https://github.com/paperclipai/paperclip/actions/runs/26055610103/job/76602841176) should now pass. ## Risks - Low risk. One-line addition that copies a single script earlier in the Docker build. No runtime behavior changes, no app code changes, no schema changes. ## Model Used - Claude (Anthropic), model ID `claude-opus-4-7`, extended thinking enabled, 200K context. Used via Claude Code CLI with tool use (Bash, Read, Edit, Grep) running inside the Paperclip agent harness. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 20:55:34 -07:00
Dotta	a07e6cef7b	[codex] Fix new issue autocomplete pointer selection (#6311) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Human operators create and edit issues through modal-heavy board UI workflows. > - The new-issue dialog embeds markdown editors that render autocomplete menus through body-level portals. > - Radix Dialog treats those portal clicks as outside-dialog pointer events and prevents their default behavior. > - That prevention made completion items hard or impossible to select from inside the new-issue dialog. > - This pull request marks the markdown editor floating autocomplete menu as allowed dialog-external UI and extends the dialog outside-pointer handler to preserve those interactions. > - The benefit is that users can click/tap autocomplete completions while keeping the existing modal behavior intact. ## What Changed - Added a stable `data-paperclip-floating-ui` marker and explicit pointer event handling to the markdown editor mention/autocomplete portal. - Updated the new issue dialog outside-pointer guard so editor autocomplete portals are handled like Radix popover portals. - Added regression coverage for markdown editor portal markup and new issue dialog completion selection behavior. ## Verification - `pnpm exec vitest run ui/src/components/MarkdownEditor.test.tsx ui/src/components/NewIssueDialog.test.tsx` passed: 2 files, 38 tests. - Confirmed the branch is rebased onto current `public-gh/master` before opening this PR. - Confirmed the diff does not include `pnpm-lock.yaml` or `.github/workflows` changes. ## Risks - Low risk. The change is scoped to allowing pointer events from known body-level UI portals while keeping other outside-dialog pointer events under Radix Dialog control. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent with repository tool use and local command execution. Exact hosted context window is not surfaced in this runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Screenshot note: this is an interaction/event-handling fix with no visible UI change; verification is covered by the focused regression tests above. Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 14:28:49 -05:00
Devin Foley	988689947a	fix(release): publish modal plugin from ci (#6290) ... ## Thinking Path > - Paperclip keeps its core release process declarative through `scripts/release-package-manifest.json`, which decides which packages CI is allowed to publish. > - The Modal sandbox provider now exists as a first-party plugin package under `packages/plugins/sandbox-providers/modal`. > - The original Modal PR intentionally left `publishFromCi` disabled until the package had been published and the registry bootstrap concern was cleared. > - The latest reviewer comment confirms that bootstrap step is complete, so the remaining gap is only release automation configuration. > - This pull request flips the Modal manifest entry to `publishFromCi: true` so future CI-driven releases can publish `@paperclipai/plugin-modal` the same way the other releasable packages do. > - The benefit is that Modal releases no longer require a manual exception in the release pipeline. ## What Changed - Updated the `@paperclipai/plugin-modal` entry in `scripts/release-package-manifest.json` to set `publishFromCi` to `true`. ## Verification - Ran `node -e 'const m=require("./scripts/release-package-manifest.json"); const e=m.find(x=>x.name==="@paperclipai/plugin-modal"); if(!e||e.publishFromCi!==true){throw new Error("modal publishFromCi not true")}; console.log(JSON.stringify(e))'` ## Risks - Low risk. This only changes release-manifest metadata; the main failure mode is CI attempting to publish the Modal package before registry credentials or release conditions are ready. ## Model Used - OpenAI Codex local agent, GPT-5-based coding model in the Codex runtime (exact deployment model ID not exposed in this workspace), with tool use and shell execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-18 09:42:01 -07:00
Devin Foley	e5a0f5debd	fix(plugin): raise environmentProbe RPC timeout to 120s for cold-start sandboxes (#6289) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Companies provision execution environments via sandbox provider plugins (Modal, Daytona, E2B, etc.) > - At provision time, the server probes each plugin's environment / sandbox-provider driver over a worker RPC to validate config > - `workerManager.call()` defaults to a 30s timeout, but cold-start sandboxes — Modal in particular — take ~31s to boot > - Result: every fresh Modal environment probe fails with a worker RPC timeout, blocking environment provisioning end-to-end > - This PR passes `timeoutMs=120_000` to the two probe call sites (`probePluginEnvironmentDriver`, `probePluginSandboxProviderDriver`) > - The benefit is Modal — and any future provider with similar cold-start latency — can be successfully probed without false-negative timeout failures ## What Changed - Pass `timeoutMs=120_000` to `workerManager.call()` in `probePluginEnvironmentDriver` (`server/src/services/plugin-environment-driver.ts`) - Pass `timeoutMs=120_000` to `workerManager.call()` in `probePluginSandboxProviderDriver` (same file) ## Verification - Targeted unit tests: ``` pnpm --filter @paperclipai/server exec vitest run \ src/__tests__/plugin-environment-driver-seam.test.ts \ src/__tests__/heartbeat-plugin-environment.test.ts ``` 5/5 tests pass. - Manual: provision a fresh Modal sandbox environment from the UI. Previously failed with a worker RPC timeout at ~30s; now succeeds. ## Risks - Low risk. The change only raises a per-call timeout (default 30s → explicit 120s) on two probe call sites. Fast providers are unaffected since probe completes well below either bound. Worst case: a genuinely hung worker now blocks the probe for 120s instead of 30s before giving up — still bounded, and only on the provision-time probe path (not the heartbeat/run path). ## Model Used - Provider: Anthropic - Model: `claude-opus-4-7` (Claude Opus 4.7, 1M context window) - Capabilities: extended thinking, tool use, code execution - Scope of AI assistance: the underlying 4-line code change was human-authored by the committer; this PR (verification commands, message structuring, and submission) was prepared with Claude per the `paperclip-dev` skill. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [ ] I have added or updated tests where applicable — n/a, this is a per-call timeout configuration bump; existing tests cover the probe call path - [x] If this change affects the UI, I have included before/after screenshots — n/a, no UI change - [ ] I have updated relevant documentation to reflect my changes — n/a, the timeout is an internal worker-RPC tuning value with no documented contract - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 09:32:12 -07:00
Devin Foley	4b1e92a588	feat(plugins): add Modal sandbox provider plugin (#6245) ... ## Thinking Path > - Paperclip orchestrates AI agents through company-scoped control-plane workflows and extensible runtime integrations. > - Sandbox providers are part of that extension surface because they let agents execute isolated work without baking each provider into the core server. > - Modal already offers managed sandboxes with filesystem, process, timeout, and networking controls that map onto Paperclip's sandbox provider contract. > - The repo did not have a Modal provider plugin, so teams wanting Modal-backed sandboxes had no first-party integration path. > - This pull request adds a standalone `packages/plugins/sandbox-providers/modal` plugin that implements the provider contract, worker entrypoint, docs, and tests. > - The benefit is that Modal can now be installed as a provider plugin without expanding the core control-plane surface area. ## What Changed - Added a new `packages/plugins/sandbox-providers/modal` package with the plugin manifest, worker entrypoint, and exported plugin surface. - Implemented Modal-backed sandbox lifecycle support for creation, command execution, file operations, networking options, termination, and metadata translation. - Added focused Vitest coverage for config validation, env handling, lifecycle flows, networking behavior, and error mapping. - Documented installation, configuration, and usage requirements in the plugin README. - Removed misleading `MODAL_TOKEN_*` fallback behavior so authentication relies on supported Modal credentials only. ## Verification - `pnpm -r typecheck` - `pnpm test:run` - `pnpm build` - `cd packages/plugins/sandbox-providers/modal && pnpm test` ## Risks - Low to medium risk: this is isolated to a new plugin package, but runtime behavior still depends on live Modal account credentials and service-side sandbox semantics. - Modal's current docs target a newer Node baseline than the repo default, so the first live install should confirm credential loading and sandbox startup behavior in a real Modal workspace. - No UI or schema changes are included 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 via Paperclip `codex_local` agent (GPT-5-class Codex coding model; exact backend model ID is not exposed by the runtime), with tool use, shell execution, and code-editing capabilities enabled. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 08:36:34 -07:00
Dotta	8f45d12447	docs: update plugin authoring guide for managed resources (#6261) ... ## Thinking Path <!-- Required. Trace your reasoning from the top of the project down to this specific change. Start with what Paperclip is, then narrow through the subsystem, the problem, and why this PR exists. Use blockquote style. Aim for 5-8 steps. See CONTRIBUTING.md for full examples. --> > - Paperclip orchestrates AI agents for zero-human companies. > - The plugin system is how optional capabilities extend the control plane without adding hidden core behavior. > - Plugin authors need accurate guidance for the current managed capabilities model. > - The existing docs under-described managed skills and the routine-first pattern for durable plugin automation. > - Content-oriented plugins such as LLM Wiki should model recurring work with visible managed agents, projects, routines, and skills. > - This pull request aligns the authoring guide, local development guide, and longer plugin spec with that model. > - The benefit is clearer plugin guidance that preserves Paperclip visibility, budgets, pause controls, and audit trails. ## What Changed <!-- Bullet list of concrete changes. One bullet per logical unit. --> - Documented plugin-managed skills alongside managed agents, projects, and routines. - Added guidance for content-oriented plugins to use managed projects, agents, skills, and routines instead of private daemon-like state. - Updated the manifest/spec examples and capability lists for current plugin-managed surfaces. - Clarified when to use managed routines instead of plugin runtime jobs for board-visible recurring work. - Added a short local plugin development note pointing authors toward routine-first automation. - Addressed Greptile docs feedback by marking top-level `launchers` as legacy and removing a redundant `slug` from the managed skill example. ## Verification <!-- How can a reviewer confirm this works? Include test commands, manual steps, or both. For UI changes, include before/after screenshots. --> - `git diff --check public-gh/master...HEAD` - Reviewed `ROADMAP.md`; this is docs alignment for the completed plugin system milestone and does not add roadmap-level core feature work. - Greptile Review: success on the latest head; `3 files reviewed, 0 comments added` after follow-up fixes. - GitHub PR checks are green on the latest head, including Build, Typecheck + Release Registry, General tests, serialized server suites, e2e, Canary Dry Run, policy, Snyk, and aggregate `verify`. ## Risks <!-- What could go wrong? Mention migration safety, breaking changes, behavioral shifts, or "Low risk" if genuinely minor. --> - Low risk: documentation-only changes. - Main risk is documentation drift if the plugin API changes again before these docs are reviewed. > 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 <!-- Required. Specify which AI model was used to produce or assist with this change. Be as descriptive as possible - include: • Provider and model name (e.g., Claude, GPT, Gemini, Codex) • Exact model ID or version (e.g., claude-opus-4-6, gpt-4-turbo-2024-04-09) • Context window size if relevant (e.g., 1M context) • Reasoning/thinking mode if applicable (e.g., extended thinking, chain-of-thought) • Any other relevant capability details (e.g., tool use, code execution) If no AI model was used, write "None — human-authored". --> - OpenAI Codex, GPT-5 coding agent with shell and GitHub connector 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 10:14:27 -05:00
Dotta	32605b71ad	Remove planning badge from inbox issue rows (PAP-9691) (#6269) ... ## Summary - Removes the amber "Planning" pill from inbox / issue-list rows in `IssueRow` - Updates the focused IssueRow test to assert the badge is no longer rendered - Per [PAP-9691](https://paperclip.ing/PAP/issues/PAP-9691): user just doesn't want to see the badge in list rows The underlying `issue.workMode === "planning"` data, the issue detail composer toggle, and the server/plugin/heartbeat work-mode contract introduced in #5353 are all untouched. Planning mode still functions; the list-row indicator is just gone. ## Test plan - [x] `pnpm exec vitest run --project @paperclipai/ui ui/src/components/IssueRow.test.tsx` (11 passed) - [ ] Visual: open `/PAP/inbox` with a planning-mode issue assigned and confirm no amber Planning pill on the row 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-18 09:27:05 -05:00
github-actions[bot]	85510f0e5b	chore(lockfile): refresh pnpm-lock.yaml (#6263) ... Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml. Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>	2026-05-18 08:52:09 -05:00
Dotta	5071c4c776	[codex] Add workspace diff viewer plugin (#6071) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Operators need to inspect what agents changed inside execution and project workspaces. > - The existing workspace detail views did not provide a first-party rich diff surface for staged, unstaged, head, renamed, binary, oversized, and untracked changes. > - The plugin system is the intended extension point for optional rich UI surfaces. > - This pull request adds a workspace diff plugin plus host services and shared contracts so Changes tabs can render workspace diffs through plugin slots. > - The diff-renderer dependency should stay owned by the plugin package rather than the core UI app. > - The dependency surface must stay aligned with repository PR policy, including intentionally omitting `pnpm-lock.yaml` from the PR. > - The benefit is a more reviewable workspace surface without hard-coding the renderer into every page. ## What Changed - Added `@paperclipai/plugin-workspace-diff`, including diff normalization, plugin manifest/worker/UI entrypoints, and focused plugin tests. - Kept `@pierre/diffs` scoped to `@paperclipai/plugin-workspace-diff`; removed the core UI lab diff-renderer surface and direct UI package dependency. - Added shared workspace diff types and validators, plus plugin SDK surface for workspace diff host services. - Added server workspace diff service support and route coverage for execution/project workspace diff flows. - Wired Execution Workspace and Project Workspace Changes tabs to load the diff plugin, including loading/error fallback behavior. - Added UI tests and fixtures for the Changes tabs and plugin bridge behavior. - Added the new plugin package manifest to the Docker deps stage so PR policy can validate dependency coverage. - Addressed review hardening around empty untracked patches, workspace path exposure, project workspace read capability checks, and default base refs. ## Verification - `pnpm --filter @paperclipai/plugin-workspace-diff test` - `pnpm exec vitest run packages/shared/src/validators/workspace-diff.test.ts server/src/__tests__/workspace-diff-service.test.ts ui/src/pages/ProjectWorkspaceDetail.test.tsx ui/src/pages/ExecutionWorkspaceDetail.test.tsx` - `pnpm exec vitest run ui/src/plugins/bridge.test.ts server/src/__tests__/workspace-runtime-routes-authz.test.ts` - `pnpm --filter @paperclipai/shared typecheck` - `pnpm --filter @paperclipai/plugin-workspace-diff typecheck` - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/ui typecheck` - `node ./scripts/check-docker-deps-stage.mjs` - Browser screenshot captured from the local worktree dev server: https://files.catbox.moe/ofdpsp.png - Confirmed branch is rebased onto `public-gh/master`, `.github/workflows/pr.yml` is not included in the PR diff, `ui/package.json` is not included in the PR diff, and `pnpm-lock.yaml` is not included in the PR diff. ## Risks - Medium UI integration risk: the Changes tab depends on the plugin slot and host diff service path. - Medium dependency risk: this adds `@pierre/diffs` in the plugin package, but `pnpm-lock.yaml` is intentionally omitted per packaging instructions because repository automation manages lockfile updates. - Current CI blocker: downstream frozen installs fail until the repository policy path for new plugin package dependencies is chosen. - Diff rendering edge cases are covered for common working-tree and head diff states, but very large repositories may still expose performance limits. - No migrations are included. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 class coding model, tool-enabled local execution environment. Exact context window was not exposed by the runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-18 08:50:06 -05:00
Devin Foley	242a2c2f2b	fix(cli): stop worktree init --force from wiping repo worktrees/ (#6240) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Each working tree gets an isolated Paperclip instance; the CLI's `paperclip worktree init` is what bootstraps that instance and writes `<repo>/.paperclip/config.json` + `.env` > - When `--force` was passed, the init path tried to "start clean" by recursively removing the entire `<repo>/.paperclip/` directory before rewriting those two files > - But `<repo>/.paperclip/` also holds `worktrees/`, which contains every repo-managed worktree checkout (70+ on this machine). The recursive rm silently nuked all of them. > - This PR narrows the `--force` reset so it only deletes the two files it's about to rewrite (`config.json`, `.env`), instead of wiping the whole `repoConfigDir` > - It also adds a regression test that drops a sentinel file into `<repoConfigDir>/worktrees/` and asserts it survives a `--force` init > - The benefit is that `worktree init --force` becomes safe to run from inside the main repo without destroying every sibling worktree checkout ## What Changed - `cli/src/commands/worktree.ts`: in the `--force` branch of `runWorktreeInit`, replace `rmSync(paths.repoConfigDir, { recursive: true, force: true })` with targeted removals of `paths.configPath` and `paths.envPath`. `paths.instanceRoot` removal is unchanged — that path is per-instance and safe to wipe. - `cli/src/__tests__/worktree.test.ts`: new regression test that seeds a fake `worktrees/<name>/` checkout inside the repo's `.paperclip/` and verifies `runWorktreeInit({ force: true, ... })` does not delete it. ## Verification - `pnpm --filter @paperclip/cli test -- worktree` — the new regression test fails on the old code and passes on the fix - Manual: from a repo checkout, `npx paperclipai worktree init --force …` no longer removes `<repo>/.paperclip/worktrees/`; only `config.json` and `.env` are rewritten ## Risks - Low. The change strictly narrows what `--force` removes. Any caller that depended on `--force` also wiping unrelated files under `<repo>/.paperclip/` (there shouldn't be any — it's documented as just config + env) would see those files persist. `instanceRoot` cleanup is unchanged. ## Model Used - Claude (Anthropic), model `claude-opus-4-7`, ~200K context, extended-thinking + tool-use enabled, run via the Paperclip `claude_local` adapter. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots (N/A — CLI-only fix) - [x] I have updated relevant documentation to reflect my changes (no doc surface affected) - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-17 22:12:56 -07:00
Devin Foley	734385102c	Fix new secret form textarea overflow (PAPA-348) (#6222) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - Operators manage per-company secrets through the Secrets page in the web UI > - A long secret value pasted into the "New secret" textarea blew out the form's width, which pushed the Create/Cancel buttons off-screen and made the form unusable > - Root cause: the shadcn `Textarea` primitive sets `w-full` but does not constrain `min-width`, so a flex parent honors the textarea's intrinsic content width when a long unbreakable string is present > - This pull request adds `min-w-0 max-w-full` to the shared `Textarea` primitive and `min-w-0 overflow-x-hidden break-all` on the secret-value usage so a long token wraps inside the form bounds > - The benefit is the Create/Cancel buttons stay reachable regardless of pasted token length, and every other `Textarea` consumer also gets the flexbox-friendly width constraint ## What Changed - `ui/src/components/ui/textarea.tsx`: added `min-w-0 max-w-full` to the base shadcn `Textarea` so it cannot exceed its flex parent - `ui/src/pages/Secrets.tsx`: added `min-w-0 overflow-x-hidden break-all` on the new-secret value `Textarea` so long opaque tokens wrap instead of pushing the form - `ui/src/pages/Secrets.render.test.tsx`: new regression test that opens the New Secret dialog and asserts the value textarea carries the width-constraint classes ## Verification - `cd ui && npx vitest run src/pages/Secrets.render.test.tsx` — 3/3 pass - Manual: open the Secrets page, click "New secret", paste a long unbroken string (e.g. a 500-char token) into the value field. The form stays within its dialog and the Create/Cancel buttons remain in view. Before: <img width="1772" height="1432" alt="image" src="https://github.com/user-attachments/assets/cb31a290-f82a-41dc-9346-91d18cbb5911" /> After: <img width="672" height="734" alt="Screenshot 2026-05-17 at 5 39 38 PM" src="https://github.com/user-attachments/assets/a08800c2-b09b-43be-b0e8-114d9149b8f5" /> After: the value field wraps with `break-all` inside the dialog; Create/Cancel stay clickable. Covered by the new render test which asserts `min-w-0`, `overflow-x-hidden`, and `break-all` are present on `#new-secret-value`. ## Risks - Low risk. The base `Textarea` change adds `min-w-0 max-w-full`, which only affects layouts where a textarea was previously allowed to grow past its parent — those cases were already buggy. `break-all` on the secret-value textarea is the right behavior for opaque tokens; it would be wrong for prose, but this field is explicitly a secret token. ## Model Used - Provider: Anthropic Claude - Model: claude-opus-4-7 (Opus 4.7) - Mode: standard Claude Code agent, tool use enabled ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-17 17:54:15 -07:00
Dotta	d734bd43d1	[codex] Roll up May 17 branch changes (#6210) ... ## Thinking Path > - Paperclip is the control plane for autonomous AI companies, so agent work needs visible ownership, recovery, and operator controls. > - This local branch had accumulated several related control-plane reliability and operator-experience fixes across recovery actions, watchdog folding, model-profile defaults, mentions, markdown editing, plugin launchers, and small UI polish. > - The branch needed to be converted into a PR against the current `origin/master` without losing dirty work or including lockfile/workflow churn. > - The safest standalone shape is a single rollup PR because the recovery/server/UI files overlap heavily across the local commits and splitting would create avoidable conflicts. > - This pull request replays the local branch onto latest `origin/master`, preserves the uncommitted work as logical commits, and adds a Zod 4 validator compatibility fix found during verification. > - The benefit is that the May 17 local branch can be reviewed and merged as one coherent, conflict-free branch under the 100-file Greptile limit. ## What Changed - Rebased the local May 17 branch work onto current `origin/master` in a dedicated worktree. - Preserved and committed previously dirty changes for recovery retry handling, plugin/sidebar launcher polish, and `.herenow` ignores. - Added recovery-action behavior for returning source issues to `todo` when retrying source-scoped recovery. - Included the existing local recovery/liveness/watchdog fold, Codex cheap-profile, markdown/mention, duplicate-agent, and UI polish commits from the branch. - Normalized shared validator `z.record(...)` schemas to explicit string-key records for Zod 4 compatibility. - Confirmed the PR has no `pnpm-lock.yaml` or `.github/workflows/*` changes and stays below the 100-file Greptile limit. ## Verification - `pnpm install --frozen-lockfile --ignore-scripts` - `npm run install` in `node_modules/.pnpm/sqlite3@5.1.7/node_modules/sqlite3` to build the local native sqlite3 binding after installing with scripts disabled - `pnpm exec vitest run packages/shared/src/validators/issue.test.ts packages/shared/src/project-mentions.test.ts packages/adapter-utils/src/server-utils.test.ts server/src/__tests__/heartbeat-model-profile.test.ts server/src/__tests__/issue-recovery-actions.test.ts server/src/__tests__/issue-agent-mutation-ownership-routes.test.ts server/src/__tests__/heartbeat-active-run-output-watchdog.test.ts server/src/__tests__/plugin-local-folders.test.ts ui/src/components/IssueRecoveryActionCard.test.tsx ui/src/components/Sidebar.test.tsx ui/src/components/SidebarAccountMenu.test.tsx ui/src/components/IssueProperties.test.tsx ui/src/components/MarkdownEditor.test.tsx ui/src/components/MarkdownBody.test.tsx ui/src/lib/duplicate-agent-payload.test.ts ui/src/pages/Routines.test.tsx` - First pass: 13 files passed with 201 passing tests; 3 server files failed before sqlite3 native binding was built. - After rebuilding sqlite3: `server/src/__tests__/heartbeat-model-profile.test.ts`, `server/src/__tests__/issue-recovery-actions.test.ts`, and `server/src/__tests__/heartbeat-active-run-output-watchdog.test.ts` passed/loaded; embedded Postgres tests were skipped by the local host guard. - `pnpm --filter @paperclipai/shared typecheck` - `pnpm --filter @paperclipai/adapter-utils typecheck` - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/ui typecheck` ## Risks - Medium risk: this is a broad rollup PR across recovery semantics, server tests, shared validators, and UI surfaces. - Some embedded Postgres tests skipped locally due the host guard, so CI should provide the stronger database-backed signal. - UI changes were covered by component tests, but no browser screenshot was captured in this PR creation pass. - This branch may overlap with existing recovery/liveness PR work; merge this PR independently or restack/close overlapping branches rather than merging duplicate implementations together. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent, tool-enabled local repository and GitHub workflow, medium reasoning effort. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-17 17:15:06 -05:00
Dotta	705c1b8d81	[codex] Add routine env secrets support (#6212) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Scheduled routines are the control-plane path for recurring agent work. > - Routines already had dispatch/history, but their runtime environment did not carry routine-owned secret bindings through execution. > - Operators need routine-specific secrets that can override project/agent env without exposing secret values in history, logs, or access events. > - This pull request adds the routine env runtime contract, wires it into execution, and makes the routine UI/history surfaces show safe secret metadata. > - The benefit is that routine executions can use scoped secret refs predictably while preserving company boundaries and auditability. ## What Changed - Added routine env persistence/runtime support, including `routines.env`, `routine_runs.routine_revision_id`, revision snapshots, and idempotent migration `0086_routine_env_runtime_contract`. - Resolved routine env during heartbeat adapter config assembly with precedence `agent < project < routine` and secret access events recorded against the routine consumer. - Added secret binding synchronization for routine create/update/restore flows and guarded cross-company, missing, disabled, and deleted secret cases. - Added a Secrets tab to routine detail, env/secret history diff rendering, and Storybook coverage for the new UI states. - Added server/UI regression tests, including an embedded-Postgres QA path for routine secret execution and restore behavior. - Updated implementation/database docs for routine env and secret-binding behavior. ## Verification - `pnpm install --frozen-lockfile` after rebasing onto `public-gh/master` to refresh workspace links for the newly-added upstream Grok adapter package. - `pnpm exec vitest run server/src/__tests__/heartbeat-project-env.test.ts server/src/__tests__/routines-service.test.ts server/src/__tests__/secrets-service.test.ts server/src/__tests__/qa-routine-secrets-e2e.test.ts ui/src/components/RoutineHistoryTab.test.tsx` passed: 5 files, 92 tests. - `pnpm -r typecheck` passed across the workspace. - `pnpm build` passed. Vite emitted the existing large-chunk/dynamic-import warnings. - UI screenshots were captured locally during QA in `artifacts/pap-9521/` and `artifacts/pap-9522/`; generated screenshots are not committed to avoid adding binary artifacts to the repo. ## Risks - Migration risk is limited by `IF NOT EXISTS` guards for the new columns, FK, and index, and the migration is ordered as `0086` immediately after upstream `0085`. - Runtime behavior changes env precedence for routine executions by adding routine env as the highest-precedence layer; tests cover agent/project/routine precedence. - Secret handling is security-sensitive; tests cover value-free manifests/events/errors, disabled/missing/deleted secrets, and cross-company rejection. - UI history now renders routine env/secret diffs; tests and Storybook stories cover the main rendering paths. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex coding agent based on GPT-5, with shell/tool use and medium reasoning effort. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-17 16:30:34 -05:00
Dotta	3e6610fb93	docs(skills): add release-changelog-discord-message skill (#6152) ... ## Summary Adds `.agents/skills/release-changelog-discord-message/SKILL.md` — the companion to `.agents/skills/release-changelog/`. The changelog skill produces `releases/vYYYY.MDD.P.md`; this one turns that into the single copy-pasteable Discord post in dotta's voice and attaches it as the `discord_announcement` document on the release issue. Includes: - dotta's instructions near-verbatim from PAP-3687 ("This is for discord — try to follow my format. If I have a section where I think about the future, pull from recent issues we're working on etc.") - The three previous Discord announcements (v2026.403.0, v2026.416.0, v2026.427.0) **verbatim** as canonical voice references - Format template + language tips (ALL CAPS for excitement, emoji-shortcode-per-highlight, first-person voice, opener/closer brand bookends) - Workflow tied to the existing release issue + `discord_announcement` document - Review checklist (version match, contributor list dedup, real "what's next" themes, no invented work) Resolves PAP-9524. ## Test plan - [ ] dotta eyeballs voice + structure against the three prior posts - [ ] On the next release, run this skill end-to-end and confirm the `discord_announcement` document on the release issue matches the format Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-16 20:36:22 -05:00
Dotta	7bbdfb69df	[codex] Enable Grok adapter canary publishing (#6154) ... ## Thinking Path > - Paperclip publishes its CLI, server, UI, and adapter packages through the shared release workflow. > - Canary releases are driven by the GitHub release workflow on pushes to `master`. > - The release workflow does not publish every public package automatically; it uses `scripts/release-package-manifest.json` as the CI enrollment source of truth. > - The Grok adapter is public and already present in the manifest, but its `publishFromCi` flag was still disabled. > - Because of that flag, normal canary publishes skipped `@paperclipai/adapter-grok-local` even when the main package received a canary. > - This pull request enables Grok in the release manifest so future canary runs include it. > - The benefit is that Grok adapter canaries stay aligned with the rest of the package release set. ## What Changed - Set `packages/adapters/grok-local` / `@paperclipai/adapter-grok-local` to `publishFromCi: true` in `scripts/release-package-manifest.json`. ## Verification - `node ./scripts/release-package-map.mjs check` - `node ./scripts/release-package-map.mjs list | grep '@paperclipai/adapter-grok-local'` - `pnpm test:release-registry` ## Risks - Low risk: this is a release manifest-only change. - Future canary releases will attempt to publish `@paperclipai/adapter-grok-local`; this assumes the package remains publishable and trusted publishing/package access are correctly configured for the existing npm package. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-based coding agent with shell, git, and GitHub 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-16 20:34:28 -05:00
Dotta	93cd933f79	docs: add v2026.517.0 release changelog (#6150) ... ## Thinking Path > - Paperclip is the control plane for autonomous AI companies. > - Stable releases need a reviewer-readable changelog artifact that summarizes what changed for operators and contributors. > - The last stable release tag is `v2026.513.0`, and the requested release date is 2026-05-17. > - The release changelog skill maps that date to stable version `2026.517.0` and requires the range `v2026.513.0..origin/master`. > - I reviewed the commits, PR metadata, migration/API surfaces, and contributor attribution in that range. > - This pull request adds the `releases/v2026.517.0.md` changelog for human release sign-off. > - The benefit is a stable release note artifact that is ready to review before publishing the release. ## What Changed - Added `releases/v2026.517.0.md` for the 2026-05-17 stable release. - Summarized user-facing highlights, improvements, fixes, and contributor attribution from `v2026.513.0..origin/master`. - Omitted Breaking Changes and Upgrade Guide sections after checking for destructive migrations, removed API surfaces, and breaking-change commit signals. ## Verification - `./scripts/release.sh stable --date 2026-05-17 --print-version` -> `2026.517.0`. - `git tag --list 'v*' --sort=-version:refname | head -10` confirmed `v2026.513.0` is the latest stable tag. - `git log v2026.513.0..origin/master --oneline --no-merges` reviewed the 16 release-range commits. - `git diff --name-only v2026.513.0..origin/master -- .changeset` returned no changeset files. - `git log v2026.513.0..origin/master --format='%s' | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true` returned no breaking-change signals. - `git diff --name-only v2026.513.0..origin/master -- packages/db/src/migrations packages/db/src/schema server/src/routes server/src/api server/src` reviewed the DB/API/server touchpoints; only an additive document-lock migration appeared in the DB schema/migration path. - `test -f releases/v2026.517.0.md` passed. - `rg -n -- '-canary|canary/' releases/v2026.517.0.md || true` returned no canary filename/title language. - `git diff --cached --check` passed before commit. ## Risks - Low risk: docs-only release changelog addition. - Changelog grouping is editorial; reviewers may want wording or prioritization changes before release publication. - Contributor attribution intentionally excludes bot accounts and Paperclip founders from the Contributors section per the release changelog skill. > Checked [`ROADMAP.md`](ROADMAP.md); this is release documentation, not new roadmap-level core feature work. ## Model Used - OpenAI Codex, GPT-5 coding agent via Paperclip `codex_local`, with shell, git, GitHub CLI, and repository file editing enabled. Exact backend sub-version and context window were not surfaced by the Paperclip runtime. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-16 19:32:24 -05:00
Devin Foley	573e9ec909	fix(grok-local): restore turn boundaries in streaming reasoning text (#6142) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies > - The `grok-local` adapter streams reasoning text to the issue "Working..." panel as the grok CLI runs > - The `grok` CLI's `--output-format streaming-json` mode silently drops the `\n` separator between reasoning turns around tool calls > - Consecutive `thought` chunks (e.g. `` "`" `` followed by `"The"`) arrive with no intervening whitespace event, so the UI's `delta: true` concatenator merged them into run-on text like `"…planningGreat, now I have the issue descriptionThe only co"` > - This PR adds a small turn-boundary helper that detects sentence boundaries in the upstream `thought` stream and inserts a single `\n` only when the previous chunk ended with sentence punctuation (or a balanced closing backtick) AND the next chunk begins a new uppercase sentence > - The benefit is readable streaming reasoning in the UI without changing how completed messages are stored ## What Changed - Added `packages/adapters/grok-local/src/shared/turn-boundary.ts` with per-stream state (last chunk + backtick parity) and a `restoreTurnBoundary()` helper that inserts `\n` only between balanced, sentence-terminated `thought` chunks - Wired the helper into `parseGrokJsonl` (server) and added a new `createGrokStdoutParser` factory used by `grokLocalUIAdapter` for the live "Working..." panel - Added focused tests in `shared/turn-boundary.test.ts`, plus regression assertions in `server/parse.test.ts` and `ui/parse-stdout.test.ts` ## Verification - `pnpm --filter @paperclip/grok-local test` — 23/23 adapter tests pass - `pnpm --filter @paperclip/grok-local typecheck` and UI typecheck — clean - Replayed an actual broken `grok 0.1.210` stream from the report; previously-merged boundaries (`` `ls`The ``, `returned:Confirmed`) now render with a separating newline; chunks inside un-closed backtick spans are left alone ## Risks - Low risk. Boundary insertion only fires when prev ends with `.`/`!`/`?`/balanced `` ` `` and next begins with an uppercase ≥2-char word, with no whitespace on either side. Worst case: a rare missed split or a misplaced newline inside reasoning — both purely cosmetic and confined to the live streaming panel. ## Model Used - Claude Opus 4.7 (claude-opus-4-7), Anthropic, extended thinking + 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-16 11:48:51 -07:00
Devin Foley	81d18f2d77	ci: speed up PR verify workflow (#6137) ... ## Thinking Path > - Paperclip orchestrates AI agents through a control-plane repo that relies on GitHub Actions as part of its release and verification safety net. > - The PR workflow in `.github/workflows/pr.yml` is the core CI path protecting pull requests before merge. > - Baseline measurement work in [PAPA-335](/PAPA/issues/PAPA-335) showed the old single `verify` job was the critical-path bottleneck, with general tests and build serialized together. > - Follow-up implementation in [PAPA-338](/PAPA/issues/PAPA-338) and [PAPA-339](/PAPA/issues/PAPA-339) split that work into parallel lanes and removed redundant clean-runner prebuild work. > - [PAPA-340](/PAPA/issues/PAPA-340) now needs real post-change PR workflow evidence, not local inference, to compare against the May 15, 2026 baseline and decide whether phase-2 work is still justified. > - This pull request publishes the already-implemented CI speedup branch so GitHub can run the actual `PR` workflow against it. > - The benefit is that CI timing decisions are based on measured runs from the exact workflow shape we intend to ship. ## What Changed - Split the PR workflow so `policy` fans out into separate `Typecheck + Release Registry`, grouped `General tests`, and `Build` jobs. - Kept the serialized server matrix, canary dry run, and e2e jobs intact while removing the old monolithic `verify` bottleneck. - Reworked grouped general-test execution in `scripts/run-vitest-stable.mjs` so the workflow can run balanced non-serialized lanes. - Replaced redundant clean-runner prebuild gates with the idempotent `ensure-build-deps` path used by the relevant CI entrypoints. ## Verification - `ruby -e "require 'yaml'; YAML.load_file('.github/workflows/pr.yml'); puts 'yaml-ok'"` - `node scripts/run-vitest-stable.mjs --mode general --dry-run` - `node scripts/run-vitest-stable.mjs --mode general --group general-server --dry-run` - `node scripts/run-vitest-stable.mjs --mode general --group general-workspaces-a --dry-run` - `node scripts/run-vitest-stable.mjs --mode general --group general-workspaces-b --dry-run` - `pnpm test:run:general -- --group general-workspaces-b` - `pnpm test:run:general -- --group general-workspaces-a` - `pnpm test:run:general -- --group general-server` - `pnpm run typecheck:build-gaps` - `pnpm --filter @paperclipai/plugin-hello-world-example typecheck` ## Risks - Required-check and branch-protection settings may still reference the old single `verify` job name. - Parallel CI lanes can expose hidden ordering assumptions or clean-runner bootstrap gaps that local grouped dry-runs did not surface. - Because the branch is behind current `master`, merge conflicts or unrelated upstream drift could affect the measured runtime until the branch is rebased. > Checked `ROADMAP.md`; this work is CI throughput maintenance for the existing PR verification path, not duplicate feature work. ## Model Used - OpenAI Codex via Paperclip `codex_local`, GPT-5-class coding agent with repository read/write, shell execution, and GitHub CLI/tool use. The runtime does not expose a more specific backend model ID in-session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-16 11:28:25 -07:00
github-actions[bot]	9b6d2e6b79	chore(lockfile): refresh pnpm-lock.yaml (#6136) ... Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml. Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>	2026-05-16 10:13:22 -07:00
Devin Foley	ab8b471685	Add built-in grok_local adapter (#6087) ... ## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, so adapter quality directly affects what runtimes the control plane can supervise. > - Local CLI adapters are one of the core execution surfaces because they turn real coding tools into Paperclip-managed employees with heartbeats, transcripts, and reviewability. > - Grok Build was installed on the Paperclip host, but Paperclip had no built-in `grok_local` adapter, so the runtime could not be configured through the normal server/UI/CLI adapter path. > - That gap needed to be closed with the same built-in registry, environment diagnostics, transcript parsing, and skill/instructions behavior that the other local adapters already rely on. > - After the initial adapter landed, a real follow-up run showed that Grok streaming text was being rendered one fragment per line, which made transcripts harder to read even though the runtime itself was working. > - This pull request adds the built-in `grok_local` adapter end-to-end and then fixes the transcript parser so streamed Grok output is coalesced into readable assistant/thinking blocks. > - The benefit is that Grok Build becomes a first-class Paperclip runtime with a usable operator experience instead of a partially wired runtime with noisy transcript output. ## What Changed - Added a new built-in `@paperclipai/adapter-grok-local` package with server, UI, and CLI entrypoints. - Implemented Grok execution, session handling, environment diagnostics, config building, skill syncing, and parser coverage inside the new adapter package. - Registered `grok_local` across the built-in adapter inventories and capability/display metadata in server, UI, CLI, and shared constants. - Added adapter route coverage for the new built-in type. - Fixed Grok transcript readability by emitting streamed `text` and `thought` fragments as deltas so the shared transcript builder coalesces them into readable message blocks. - Added regression tests for the Grok parser and transcript coalescing behavior. ## Verification - `pnpm vitest run packages/adapters/grok-local/src/ui/parse-stdout.test.ts ui/src/adapters/transcript.test.ts` - `pnpm --filter @paperclipai/adapter-grok-local build` - Manual runtime verification on the Paperclip host during implementation and follow-up review: - confirmed the Grok CLI was installed and authenticated - confirmed the worktree dev server could be restarted cleanly and health-checked after the parser follow-up - No screenshots attached. This change is primarily adapter plumbing plus transcript formatting behavior; reviewers can verify via the Grok-backed run surfaces directly. ## Risks - This adds a new built-in adapter, so any missed registration surface could create inconsistencies between server, UI, and CLI behavior. - The adapter depends on Grok Build's current event/output shape; if upstream Grok streaming JSON changes, transcript parsing or session extraction may need follow-up updates. - The transcript readability fix intentionally changes how Grok fragments are grouped, so any downstream code that implicitly expected one entry per fragment would behave differently. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex via Paperclip `codex_local` agent runtime. - GPT-5-class coding model with tool use, shell execution, file editing, and repo inspection enabled. - Exact backend model ID/context window were not surfaced to the agent in this Paperclip session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-05-16 09:51:09 -07:00
Dotta	63821bfe4c	[codex] Add full locale catalog (#6070) ... ## Thinking Path > - Paperclip orchestrates AI agents through a board-facing control plane. > - The UI is the operator surface where onboarding and company creation flows need to remain understandable across languages. > - The i18next foundation now supports locale resource loading and validation, but only English was present on `master`. > - The branch exists to populate that foundation with the supported language catalog without changing routing, data contracts, or runtime behavior. > - This pull request adds locale JSON resources for the current non-English language set. > - The benefit is that future locale selection work has validated message catalogs ready for the first translated onboarding strings. ## What Changed - Added 39 localized message catalogs under `ui/src/i18n/locales/` for the existing no-companies onboarding strings. - Kept the PR rebased onto current `master` so it only contains the all-languages layer on top of the already-merged i18next foundation. ## Verification - `pnpm exec vitest run ui/src/i18n/locale-validation.test.ts` - Checked `ROADMAP.md`; this is scoped locale catalog follow-up work and does not duplicate a listed roadmap feature. - No before/after screenshots included because this PR only adds resource JSON files and does not change rendered layout or visible default-English UI behavior. ## Risks - Low risk: static JSON resource additions validated against the English reference schema. - Translation quality may need native-speaker review before enabling visible locale switching broadly. > 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 CLI, GPT-5 family coding agent, tool-enabled repository access, medium reasoning effort. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-05-16 08:24:31 -05:00