mirror of
https://github.com/alkimake/paperclip.git
synced 2026-06-14 18:10:39 +09:00
## Thinking Path > - Paperclip orchestrates AI-agent companies through a control plane that can start, supervise, and recover agent runs. > - Local adapters are the bridge between Paperclip issues and concrete agent runtimes such as Claude, Codex, and other ACP-compatible tools. > - The roadmap calls out broader “bring your own agent” and claw-style agent support, and ACPX gives Paperclip one path to normalize multiple ACP agents behind a single adapter. > - The branch needed to become one reviewable PR against current `paperclipai/paperclip:master`, without carrying stale base conflicts or generated lockfile churn. > - This pull request adds an experimental built-in `acpx_local` adapter, integrates it through the server/CLI/UI adapter surfaces, and adds regression coverage for runtime execution, skill sync, stream parsing, diagnostics, and log redaction. > - The benefit is that Paperclip can run Claude/Codex/custom ACP agents through ACPX while keeping operator configuration, skills, logging, and transcript rendering inside the existing adapter model. ## What Changed - Added `@paperclipai/adapter-acpx-local` with server execution, config schema, ACPX session handling, CLI formatting, UI config helpers, and stdout parsing. - Registered `acpx_local` across CLI, server, shared constants, UI adapter metadata, adapter capabilities, and agent creation/editing surfaces. - Added ACPX runtime execution support with persistent sessions, local-agent JWT environment handling, skill snapshots, runtime skill materialization, and isolation/security regressions. - Added ACPX adapter diagnostics and marked the adapter experimental in the UI. - Added command/env secret redaction for resolved command metadata in adapter-utils, server event storage, and the Agent Detail invocation UI. - Added Storybook coverage for ACPX config, transcript rendering, and skill states, plus PR screenshots under `docs/pr-screenshots/pap-2944/`. - Rebased the branch onto current `public-gh/master`; `pnpm-lock.yaml` is intentionally not included and there are no migration/schema changes. ## Verification - `pnpm exec vitest run packages/adapters/acpx-local/src/server/execute.test.ts packages/adapters/acpx-local/src/server/test.test.ts packages/adapters/acpx-local/src/cli/format-event.test.ts packages/adapters/acpx-local/src/ui/parse-stdout.test.ts packages/adapter-utils/src/server-utils.test.ts server/src/__tests__/redaction.test.ts server/src/__tests__/acpx-local-execute.test.ts server/src/__tests__/acpx-local-skill-sync.test.ts server/src/__tests__/acpx-local-adapter-environment.test.ts server/src/__tests__/adapter-routes.test.ts server/src/__tests__/agent-skills-routes.test.ts ui/src/adapters/metadata.test.ts` — 12 files, 87 tests passed. - `pnpm --filter @paperclipai/adapter-acpx-local typecheck` — passed. - `pnpm --filter @paperclipai/server typecheck` — passed. - `pnpm --filter @paperclipai/ui typecheck` — passed. - Confirmed PR diff does not include `pnpm-lock.yaml`, database schema files, or migrations. Screenshots:    ## Risks - Medium risk: this introduces a new built-in adapter package and touches runtime execution, adapter registration, agent config, skills, and transcript rendering. - ACPX and ACP agent behavior can vary by installed tool versions; the adapter is marked experimental to set operator expectations. - `pnpm-lock.yaml` is excluded per repository PR policy, so dependency lock refresh must be handled by the repo’s automation or maintainers. - No database migration risk: no schema or migration files changed. > 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 repository tool use, shell execution, git operations, and local verification. Exact hosted context window was 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 - [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>
86 lines
3 KiB
TypeScript
86 lines
3 KiB
TypeScript
/**
|
|
* Adapter metadata utilities — built on top of the display registry and UI adapter list.
|
|
*
|
|
* This module bridges the static display metadata with the dynamic adapter registry.
|
|
* "Coming soon" status is derived from the display registry's `comingSoon` flag.
|
|
* "Hidden" status comes from the disabled-adapter store (server-side toggle).
|
|
*/
|
|
import type { UIAdapterModule } from "./types";
|
|
import { listUIAdapters } from "./registry";
|
|
import { isAdapterTypeHidden } from "./disabled-store";
|
|
import { getAdapterLabel, getAdapterDisplay } from "./adapter-display-registry";
|
|
|
|
export interface AdapterOptionMetadata {
|
|
value: string;
|
|
label: string;
|
|
comingSoon: boolean;
|
|
hidden: boolean;
|
|
experimental: boolean;
|
|
}
|
|
|
|
export function listKnownAdapterTypes(): string[] {
|
|
return listUIAdapters().map((adapter) => adapter.type);
|
|
}
|
|
|
|
/**
|
|
* Check whether an adapter type is enabled (not "coming soon").
|
|
* Unknown types (external adapters) are always considered enabled.
|
|
*/
|
|
export function isEnabledAdapterType(type: string): boolean {
|
|
// Check display registry first — built-in adapters like process/http are
|
|
// intentionally withheld even though they're registered as UI adapters.
|
|
if (getAdapterDisplay(type).comingSoon) return false;
|
|
// All other types (registered or external) are enabled.
|
|
return true;
|
|
}
|
|
|
|
/**
|
|
* Check whether an adapter type is a valid choice for new agent creation.
|
|
* Includes all registered UI adapters (built-in + external) and
|
|
* any non-"coming soon" adapter from the display registry.
|
|
*/
|
|
export function isValidAdapterType(type: string): boolean {
|
|
if (getAdapterDisplay(type).comingSoon) return false;
|
|
return true;
|
|
}
|
|
|
|
/**
|
|
* Check whether an adapter should appear in card-style visual pickers.
|
|
* Experimental adapters can remain selectable from explicit configuration
|
|
* dropdowns without being recommended during onboarding or setup flows.
|
|
*/
|
|
export function isVisualAdapterChoice(type: string): boolean {
|
|
return !getAdapterDisplay(type).hideFromVisualSelection;
|
|
}
|
|
|
|
/**
|
|
* Build option metadata for a list of adapters (for dropdowns).
|
|
* `labelFor` callback allows callers to override labels; defaults to display registry.
|
|
*/
|
|
export function listAdapterOptions(
|
|
labelFor?: (type: string) => string,
|
|
adapters: UIAdapterModule[] = listUIAdapters(),
|
|
): AdapterOptionMetadata[] {
|
|
const getLabel = labelFor ?? getAdapterLabel;
|
|
return adapters.map((adapter) => ({
|
|
value: adapter.type,
|
|
label: getLabel(adapter.type),
|
|
comingSoon: !!getAdapterDisplay(adapter.type).comingSoon,
|
|
hidden: isAdapterTypeHidden(adapter.type),
|
|
experimental: !!getAdapterDisplay(adapter.type).experimental,
|
|
}));
|
|
}
|
|
|
|
/**
|
|
* List UI adapters excluding those hidden via the Adapters settings page.
|
|
*/
|
|
export function listVisibleUIAdapters(): UIAdapterModule[] {
|
|
return listUIAdapters().filter((a) => !isAdapterTypeHidden(a.type));
|
|
}
|
|
|
|
/**
|
|
* List visible adapter types (for non-React contexts like module-level constants).
|
|
*/
|
|
export function listVisibleAdapterTypes(): string[] {
|
|
return listVisibleUIAdapters().map((a) => a.type);
|
|
}
|