Dotta
560e7e48b5
## 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
4.4 KiB
Adding a Harness
Every Paperclip Runner harness must declare its permission behavior as part of the provider contract. A driver is not complete until its permission modes, maximum non-interactive default, durable request translation, recovery identity, isolation behavior, and conformance coverage are defined.
Current permission catalog
| Provider | Agent configuration key | Supported values | Default |
|---|---|---|---|
| Codex | codexPermissionMode |
never, on-request, untrusted |
never |
| OpenCode | opencodePermissionMode |
allow, ask, deny |
allow |
| ACPX (Claude, Codex) | acpxPermissionMode |
approve-all, approve-reads, deny-all |
approve-all |
The browser-safe source of truth for labels, defaults, and configuration
validation is PAPERCLIP_RUNNER_PERMISSION_CAPABILITIES in
@paperclipai/adapter-utils. Native process boundaries validate the pinned
provider value again; they must not silently accept an unknown mode.
“Full auto” means the harness does not pause for a duplicate approval inside the environment assigned to the run. It does not grant host-wide filesystem access, unrestricted network access, Paperclip credentials, or write access in read-only planning mode. Workspace containment, protected-path and symlink checks, network policy, credential bindings, and authenticated PRP authorization remain authoritative and run before any harness auto-approval.
Driver requirements
When adding or upgrading a harness:
- Declare the exact native modes supported by the provider. Choose the provider's highest non-interactive mode as the default for a fresh Paperclip Runner execution.
- Add its labels, configuration key, options, and default to the shared provider-discriminated capability catalog. The agent form must show only the selected provider's setting and retain stored choices when the provider selection changes.
- Pin the effective value in native execution input and provider recovery state. Include it in provider-session compatibility so changing a mode replaces an incompatible warm session rather than mutating an active turn.
- Translate every lower-mode prompt into the canonical runtime-request lifecycle: emit one durable request, recover it after reconnect, accept allow-once, allow-for-session, deny, and cancellation where the provider supports them, and send exactly one provider-native resolution.
- Authorize Paperclip semantic and question tools through authenticated PRP. These tools may bypass duplicate harness approval, but never their control-plane authorization.
- Emit the provider and effective permission mode in session-start diagnostics without including credentials or unredacted provider input.
- Keep standalone local adapters unchanged unless their own contract is
deliberately revised. Paperclip Runner defaults apply only to
paperclip_runnerexecutions.
Compatibility rules
Native execution input v4 pins approvalPolicy for Codex and
permissionMode for OpenCode and ACPX. Persisted v1-v3 executions remain
replayable. Their missing Codex and OpenCode settings use the historical
effective behavior, and legacy ACPX permissionPolicy: "interactive" means
the historical approve-reads behavior. Legacy fields are readable only;
new agent configuration must not persist them.
Do not rewrite an active execution when configuration changes. A fresh execution carries the new policy and replaces an incompatible idle or checkpointed session through normal session-compatibility handling.
Conformance checklist
A new driver must cover:
- agent create/edit defaults, selected-provider visibility, provider switching, invalid-value rejection, and no Runner sandbox-bypass control;
- native serialization, legacy replay, recovery identity, and replacement after a permission change;
- start and resume propagation for every supported mode;
- no runtime request in the maximum mode;
- once, session, and deny resolution in prompting modes, including every provider event version the driver accepts;
- immediate rejection in deny mode;
- workspace and protected-path denial before auto-approval;
- authenticated semantic-tool behavior; and
- an end-to-end default-mode write plus validation command that completes without an Input needed permission card.
Run TypeScript, Rust, UI, protocol-generation, durable transport, and documentation validation before declaring the harness qualified.