mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-06 21:05:21 +02:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Adapter names are part of the board-facing agent setup and management experience. > - The product now treats adapters as harnesses, while execution environments are modeled separately. > - Several built-in adapter labels still carried legacy local wording from the older harness-by-environment model. > - That wording makes the UI noisier and implies a distinction users no longer need to reason about. > - This pull request normalizes adapter display labels while keeping persisted adapter type identifiers unchanged. > - The benefit is clearer adapter selection and management copy without a database migration. ## Linked Issues or Issue Description No public GitHub issue was found for this exact cleanup. Related public PRs: - Supersedes #8910, an earlier branch for the same cleanup that did not include the later docs/gateway/Cursor alignment. - Refs #8819, which is related display-registry work for external multi-segment adapter labels, but not a duplicate of this built-in label cleanup. Feature request details: - Subsystem affected: Cross-cutting (`ui/`, `packages/adapters`, and docs). - Problem or motivation: user-facing adapter names include legacy local qualifiers even though adapters map to harnesses and environments are first-class elsewhere. - Proposed solution: remove the legacy local wording from built-in display labels, keep machine-readable adapter type ids unchanged, and keep gateway disambiguation where it is useful. - Alternatives considered: changing persisted adapter type ids was ruled out because it would create migration and compatibility risk; one-off UI replacements were ruled out because the display registry is already the correct central label boundary. - Roadmap alignment: this is small adapter UX polish, not a new roadmap-level core feature. ## What Changed - Updated the adapter display registry so known adapter labels are final and no built-in local adapter renders a legacy local suffix. - Preserved clean derived labels for unknown plugin local types while keeping gateway disambiguation for unknown gateway types. - Updated `AdapterManager` to prefer registry labels when the server reports raw adapter type ids for built-ins. - Removed legacy local wording from built-in adapter metadata labels in UI and adapter packages. - Aligned Cursor adapter metadata with the central display registry label. - Updated adapter docs and Storybook fixtures to match the new display names. - Added focused registry coverage for built-in labels and unknown plugin suffix behavior. ## Verification - `pnpm check:tokens` - `git diff --check origin/master...fix/adapter-display-labels` - Patch-addition scan for added secrets, private paths, and internal links: no matches. - GitHub duplicate search for open adapter-label/local-suffix issues and PRs; #8910 was identified as the older superseded public PR. - `pnpm exec vitest run ui/src/adapters/adapter-display-registry.test.ts` - `pnpm --filter @paperclipai/ui typecheck` - Stale-label scan found no remaining user-facing display-label suffixes; remaining local wording is operational/test terminology such as adapter ids, docs about running locally, and test descriptions. ## Risks Low risk. The change is display-label and documentation focused, and adapter type ids remain unchanged. The main risk is ambiguous gateway naming, mitigated by keeping explicit gateway labels where variants need disambiguation. ## Model Used OpenAI GPT-5 via Codex, tool-enabled coding agent in a local repository workspace. Context window size is not exposed by this environment. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>
4.5 KiB
4.5 KiB
title, summary
| title | summary |
|---|---|
| Architecture | Stack overview, request flow, and adapter model |
Paperclip is a monorepo with four main layers.
Stack Overview
┌─────────────────────────────────────┐
│ React UI (Vite) │
│ Dashboard, org management, tasks │
├─────────────────────────────────────┤
│ Express.js REST API (Node.js) │
│ Routes, services, auth, adapters │
├─────────────────────────────────────┤
│ PostgreSQL (Drizzle ORM) │
│ Schema, migrations, embedded mode │
├─────────────────────────────────────┤
│ Adapters │
│ Claude Code, Codex, │
│ Process, HTTP │
└─────────────────────────────────────┘
Technology Stack
| Layer | Technology |
|---|---|
| Frontend | React 19, Vite 6, React Router 7, Radix UI, Tailwind CSS 4, TanStack Query |
| Backend | Node.js 20+, Express.js 5, TypeScript |
| Database | PostgreSQL 17 (or embedded PGlite), Drizzle ORM |
| Auth | Better Auth (sessions + API keys) |
| Adapters | Claude Code CLI, Codex CLI, shell process, HTTP webhook |
| Package manager | pnpm 9 with workspaces |
Repository Structure
paperclip/
├── ui/ # React frontend
│ ├── src/pages/ # Route pages
│ ├── src/components/ # React components
│ ├── src/api/ # API client
│ └── src/context/ # React context providers
│
├── server/ # Express.js API
│ ├── src/routes/ # REST endpoints
│ ├── src/services/ # Business logic
│ ├── src/adapters/ # Agent execution adapters
│ └── src/middleware/ # Auth, logging
│
├── packages/
│ ├── db/ # Drizzle schema + migrations
│ ├── shared/ # API types, constants, validators
│ ├── adapter-utils/ # Adapter interfaces and helpers
│ └── adapters/
│ ├── claude-local/ # Claude Code adapter
│ └── codex-local/ # OpenAI Codex adapter
│
├── skills/ # Agent skills
│ └── paperclip/ # Core Paperclip skill (heartbeat protocol)
│
├── cli/ # CLI client
│ └── src/ # Setup and control-plane commands
│
└── doc/ # Internal documentation
Request Flow
When a heartbeat fires:
- Trigger — Scheduler, manual invoke, or event (assignment, mention) triggers a heartbeat
- Adapter invocation — Server calls the configured adapter's
execute()function - Agent process — Adapter spawns the agent (e.g. Claude Code CLI) with Paperclip env vars and a prompt
- Agent work — The agent calls Paperclip's REST API to check assignments, checkout tasks, do work, and update status
- Result capture — Adapter captures stdout, parses usage/cost data, extracts session state
- Run record — Server records the run result, costs, and any session state for next heartbeat
Adapter Model
Adapters are the bridge between Paperclip and agent runtimes. Each adapter is a package with three modules:
- Server module —
execute()function that spawns/calls the agent, plus environment diagnostics - UI module — stdout parser for the run viewer, config form fields for agent creation
- CLI module — terminal formatter for
paperclipai run --watch
Built-in adapters: claude_local, codex_local, process, http. You can create custom adapters for any runtime.
Key Design Decisions
- Control plane, not execution plane — Paperclip orchestrates agents; it doesn't run them
- Company-scoped — all entities belong to exactly one company; strict data boundaries
- Single-assignee tasks — atomic checkout prevents concurrent work on the same task
- Adapter-agnostic — any runtime that can call an HTTP API works as an agent
- Embedded by default — zero-config local mode with embedded PostgreSQL