0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-10-17 20:09:05 +02:00

Files

T

Dotta 560e7e48b5 feat(runner): add SDK and developer tooling (#12608 )

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The runner package already provides the production protocol and
execution spine.
> - Contributors still need stable SDK surfaces, deterministic test
tools, and local inspection tools.
> - Those surfaces share generated contracts and must change as one
package boundary.
> - This pull request adds the package-local SDK, labs, examples, and
drift checks.
> - The benefit is a reviewable developer platform that does not change
application execution selection.

## Linked Issues or Issue Description

**Subsystem affected**

`packages/paperclip-runner` — runner SDK, conformance tools, and
developer tooling.

**Problem or motivation**

The production runner spine is present, but package consumers cannot
build deterministic integrations, inspect sessions, or verify
provider-neutral behavior through supported surfaces.

**Proposed solution**

Add browser, React, standalone, live-session, scenario, conformance, and
evaluation surfaces. Add generated contract inventories and
package-local verification scripts. Keep production application routing
unchanged.

**Alternatives considered**

We considered splitting each generated catalog, SDK surface, and demo
into separate pull requests. Those changes share exports, fixtures, and
drift gates. Splitting them would create intermediate package states
that do not build.

**Roadmap alignment**

No overlapping item appears in `ROADMAP.md`. This work extends the
runner package that is already on `master`.

## What Changed

- Add browser, React, standalone, live-session, and issue-thread SDK
surfaces.
- Add deterministic mock control-plane, scenario, conformance, replay,
and evaluation tools.
- Add bounded Codex, OpenCode, and ACPX development transports and
fixtures.
- Keep deferred managed-provider execution fail-closed. Persisted
compatibility data remains readable.
- Add generated capability inventories with their source files and drift
checks.
- Add examples, package documentation, browser checks, and
clean-consumer checks.
- Preserve the reviewed protocol bounds, replay compatibility aliases,
process environment isolation, and semantic redaction limits.
- Update the ACPX package patch that the existing workspace patch
registry already tracks.
- Do not change `pnpm-lock.yaml`, repository workflows, server runtime
selection, or the application UI.

## Verification

GitHub Actions is the verification authority for this pull request. The
repository CI, package TypeScript and Rust checks, package tests,
generated-output drift checks, browser checks, security scans, and
Greptile review must pass on the exact head.

Local test suites were not run because this series uses parallel GitHub
Actions for verification.

## Risks

This is a large greenfield package change. The main risks are public
export drift, generated-output drift, and optional React consumer
compatibility. Package boundary checks, clean-consumer checks, and
browser tests cover those risks. Production adapter selection and server
execution are outside this pull request.

## Stack

1. **This PR:** runner SDK and developer tooling.
2. [Codex production server
integration](https://github.com/paperclipai/paperclip/pull/12616).
3. [Provider-neutral task-thread
UI](https://github.com/paperclipai/paperclip/pull/12617).

## Model Used

OpenAI Codex, GPT-5, high-reasoning mode, with tool use and code
execution.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have described the issue in-PR following the feature request
template
- [x] I have not referenced internal/instance-local Paperclip issues or
links
- [x] My branch name describes the change and contains no internal
Paperclip ticket id
- [ ] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

2026-08-31 21:33:11 -05:00

3.8 KiB

Raw Blame History

Capability Capability Disposition

This page explains how Capability classifies every Paperclip capability. The classification itself lives in a generated file, the Capability contract, which carries a "DO NOT EDIT" header and is rewritten by generate:capability-inventory. Read this page to understand what the generated table means; read the table for the authoritative rows.

Normative sources

Only two sources are normative:

The Paperclip skill and its seven references (SKILL.md plus references/*.md), contributing 152 headings.
The Paperclip Evals corpus, contributing 106 cases across 16 groups.

Together these produce 258 normative rows. The legacy Paperclip MCP tool surface (41 tools) is not a production capability surface; each MCP name is folded one-to-one into a normative eval row as a traceability alias and inherits that row's disposition. The contract prints the alias index only so the normative target is easy to audit.

The three dispositions

Every capability is classified as exactly one of:

control_plane_owned — the control plane performs this; no agent tool exists for it. Checkout, inbox resolution, blocker diagnostics, and status arbitration are control-plane-owned. In the explorer these appear as control-plane actions labelled "no agent tool exists for this," never as a callable tool.
always_agent_tool — the agent always has this as a semantic tool. Adding a comment, writing a document, opening an interaction, and registering a deliverable are always-agent-tool capabilities.
optional_agent_tool — the agent may have this tool, but only when a grant unlocks it. Absent the grant, the capability is not exposed and calling it is denied. See authorization and exposure.

The disposition is what makes the boundary legible: it states, per capability, whether an agent can act, must wait for the control plane, or needs a grant first.

Reading the generated contract

The contract has three parts:

Baseline counts — the heading, case, row, and alias totals above, plus the per-group case table.
Skill / reference rows — one row per heading, its primary disposition, and its file:line source anchor.
Legacy MCP alias index — each MCP name, the normative row it folds into, the inherited disposition, and its packages/mcp-server/src/tools.ts anchor.

Regenerating and checking

Generation reads the live in-repo skill/reference sources, the legacy MCP tool source, and the Paperclip Evals corpus, so it requires the external eval repository (via PAPERCLIP_EVALS_ROOT or a known local path) and is not part of the offline path. Checking and testing read only the checked-in derivatives under spec/capability/ and need no external repository.

# Rewrite every generated file. Requires the external Paperclip Evals corpus.
pnpm --filter @paperclipai/paperclip-runner generate:capability-inventory

# Validate counts, uniqueness, normative dispositions, one-to-one MCP folds,
# required fields, and generated-file drift. Offline; no external eval repo.
pnpm --filter @paperclipai/paperclip-runner check:capability-inventory

# Prove the validator rejects an independent MCP classification and rejects
# missing, duplicate, or unknown MCP folds. Offline.
pnpm --filter @paperclipai/paperclip-runner test:capability-inventory

check:capability-inventory diffs the checked-in generated files against what the live in-repo sources imply and fails on any drift or stale anchor, so the contract cannot silently fall out of sync.

3.8 KiB Raw Blame History