Arnike/paperclip
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,727 Commits 2 Branches 0 Tags
93291df5c81b89817d7c39bfd6d43c919fc46552
Commit Graph

4 Commits

Author SHA1 Message Date
Devin Foley 93291df5c8 fix(plugins): move dev SDK linking out of plugin postinstall scripts (#8255) 
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Sandbox-provider plugins (cloudflare, daytona, e2b, exe-dev,
kubernetes, modal, novita) and `plugin-workspace-diff` are published as
standalone npm packages, but during local dev they need the in-repo
`@paperclipai/plugin-sdk` symlinked in
> - Each of these plugins shipped a `postinstall` lifecycle script that
traversed *out* of its own package directory (`node
../../../../scripts/link-plugin-dev-sdk.mjs`) to do that linking
> - The publishable manifest is built by a `prepack` whitelist that
drops the `scripts` field, so npm consumers don't see the postinstall
today — but that safety property depends entirely on `prepack` running
on every publish. A publish that skips lifecycle scripts would ship a
tarball whose postinstall escapes its package directory at consumer
install time
> - This pull request removes the escape-the-package-dir lifecycle
script from every plugin source manifest and moves the dev linking to a
single root-level postinstall that iterates the excluded plugin
directories itself
> - The benefit is that plugin tarballs can no longer carry an
install-time script that reaches outside their own directory, regardless
of whether `prepack` runs

## Linked Issues or Issue Description

This is a follow-up hardening change flagged during review of the Novita
sandbox provider PR (#7595).

**Problem (security):** Excluded plugin packages each carried
`"postinstall": "node ../../../../scripts/link-plugin-dev-sdk.mjs"`. The
relative path traverses outside the package root. Today the published
manifest is sanitized by a `prepack` whitelist that drops `scripts`, so
consumers are unaffected in the normal publish path. The risk is that
this is a defense-in-depth gap: if a publish ever skips lifecycle
scripts (e.g. `npm publish --ignore-scripts` is *not* used, or a tool
publishes the raw manifest), the tarball would ship a postinstall that
runs out-of-tree code at the consumer's install time.

## What Changed

- Added a single root `package.json` `postinstall`: `node
scripts/link-plugin-dev-sdk.mjs`.
- Rewrote `scripts/link-plugin-dev-sdk.mjs` to iterate the excluded
plugin directories itself (`packages/plugins/sandbox-providers/*` + the
orchestration smoke example) instead of relying on each plugin to invoke
it from its own cwd. Preserves both prior behaviors: leave a real
installed SDK dir alone, and skip when already correctly symlinked
(idempotent).
- Removed `scripts.postinstall` from all 7 sandbox-provider plugins
(cloudflare, daytona, e2b, exe-dev, kubernetes, modal, novita).
- Removed `scripts.postinstall` from `plugin-workspace-diff` (a pnpm
workspace member — pnpm already links the SDK, so the script was a no-op
there).

## Verification

- `node scripts/link-plugin-dev-sdk.mjs` from repo root: links the SDK
into the excluded plugins and reports skipped (already-linked) dirs;
re-running is idempotent.
- `grep -r "link-plugin-dev-sdk" packages/plugins/*/package.json
packages/plugins/sandbox-providers/*/package.json` returns no matches —
no plugin source manifest references the linker any longer.
- All affected `package.json` files re-validated as parseable JSON.

## Risks

Low risk. Dev-only tooling: the linker only runs at the repo root during
local install and only touches `node_modules/@paperclipai/plugin-sdk`
symlinks inside excluded plugin dirs. No change to published plugin
behavior or runtime code. Worst case if the root postinstall failed to
run, local dev of an excluded plugin would not find the SDK symlink —
easily re-run manually.

## Model Used

Claude Opus (claude-opus-4-8), extended reasoning, with tool use / code
execution in an agentic coding 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 searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues OR (b) described the
issue in-PR following the relevant issue template
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable (added
`scripts/link-plugin-dev-sdk.test.js`, wired into
`test:release-registry`)
- [ ] 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)
- [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>
 2026-06-18 07:45:53 -07:00
Devin Foley 20aea356cc refactor(deps-dev): bump vitest from 3.2.4 to 4.1.8 (#7581) 
## Thinking Path

> - Paperclip orchestrates AI agents for zero-human companies
> - Test infrastructure across server, ui, packages/* runs on Vitest
> - Dependabot opened a narrow bump (3.2.4 → 3.2.6), but the wider
workspace is on 3.2.4 and the major-version bridge to v4 needs a
coordinated change set across configs and tests
> - Staying on 3.x indefinitely leaves us behind on Vitest 4 (perf,
pool, and config improvements) and forces repeated patch-only dependabot
churn
> - This pull request upgrades Vitest to 4.1.8 across the workspace,
updates `server/vitest.config.ts` and `scripts/run-vitest-stable.mjs`
for the new API, and adjusts two UI tests for the new assertion
semantics
> - The benefit is a single, coherent Vitest 4 upgrade that supersedes
#7570 and gets us on the supported major line

## What Changed

- Bump `vitest` from `3.2.4` to `4.1.8` across root, `server`, `ui`, and
all `packages/*` (including plugin examples and sandbox providers)
- Update `server/vitest.config.ts` for Vitest 4 config surface
- Update `scripts/run-vitest-stable.mjs` to match the new runner
behavior
- Adjust `ui/src/components/CommentThread.test.tsx` and
`ui/src/components/MarkdownEditor.test.tsx` for Vitest 4 matcher/timing
semantics
- Refresh `pnpm-lock.yaml`

## Verification

- `pnpm install` resolves cleanly with the new lockfile
- `pnpm -w -r test` (server, ui, packages) runs under Vitest 4.1.8

## Risks

- Major-version Vitest bump: behavioral changes in pools, fake timers,
and matcher strictness can surface flake. Test config and the two UI
tests were updated to match v4 semantics; broader test runs should be
watched on CI before merge.
- Supersedes dependabot PR #7570 (3.2.4 → 3.2.6); that PR should be
closed.

## Model Used

- Claude (Anthropic) — `claude-opus-4-7`, extended thinking, 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
- [ ] 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

Closes #7570
 2026-06-05 21:11:32 -07:00
dependabot[bot] 6ac15bce31 build(deps-dev): bump esbuild from 0.27.3 to 0.28.0 (#7331) 
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.27.3 to 0.28.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/releases">esbuild's
releases</a>.</em></p>
<blockquote>
<h2>v0.28.0</h2>
<ul>
<li>
<p>Add support for <code>with { type: 'text' }</code> imports (<a
href="https://redirect.github.com/evanw/esbuild/issues/4435">#4435</a>)</p>
<p>The <a href="https://github.com/tc39/proposal-import-text">import
text</a> proposal has reached stage 3 in the TC39 process, which means
that it's recommended for implementation. It has also already been
implemented by <a
href="https://docs.deno.com/examples/importing_text/">Deno</a> and <a
href="https://bun.com/docs/guides/runtime/import-html">Bun</a>. So with
this release, esbuild also adds support for it. This behaves exactly the
same as esbuild's existing <a
href="https://esbuild.github.io/content-types/#text"><code>text</code>
loader</a>. Here's an example:</p>
<pre lang="js"><code>import string from './example.txt' with { type:
'text' }
console.log(string)
</code></pre>
</li>
<li>
<p>Add integrity checks to fallback download path (<a
href="https://redirect.github.com/evanw/esbuild/issues/4343">#4343</a>)</p>
<p>Installing esbuild via npm is somewhat complicated with several
different edge cases (see <a
href="https://esbuild.github.io/getting-started/#additional-npm-flags">esbuild's
documentation</a> for details). If the regular installation of esbuild's
platform-specific package fails, esbuild's install script attempts to
download the platform-specific package itself (first with the
<code>npm</code> command, and then with a HTTP request to
<code>registry.npmjs.org</code> as a last resort).</p>
<p>This last resort path previously didn't have any integrity checks.
With this release, esbuild will now verify that the hash of the
downloaded binary matches the expected hash for the current release.
This means the hashes for all of esbuild's platform-specific binary
packages will now be embedded in the top-level <code>esbuild</code>
package. Hopefully this should work without any problems. But just in
case, this change is being done as a breaking change release.</p>
</li>
<li>
<p>Update the Go compiler from 1.25.7 to 1.26.1</p>
<p>This upgrade should not affect anything. However, there have been
some significant internal changes to the Go compiler, so esbuild could
potentially behave differently in certain edge cases:</p>
<ul>
<li>It now uses the <a
href="https://go.dev/doc/go1.26#new-garbage-collector">new garbage
collector</a> that comes with Go 1.26.</li>
<li>The Go compiler is now more aggressive with allocating memory on the
stack.</li>
<li>The executable format that the Go linker uses has undergone several
changes.</li>
<li>The WebAssembly build now unconditionally makes use of the sign
extension and non-trapping floating-point to integer conversion
instructions.</li>
</ul>
<p>You can read the <a href="https://go.dev/doc/go1.26">Go 1.26 release
notes</a> for more information.</p>
</li>
</ul>
<h2>v0.27.7</h2>
<ul>
<li>
<p>Fix lowering of define semantics for TypeScript parameter properties
(<a
href="https://redirect.github.com/evanw/esbuild/issues/4421">#4421</a>)</p>
<p>The previous release incorrectly generated class fields for
TypeScript parameter properties even when the configured target
environment does not support class fields. With this release, the
generated class fields will now be correctly lowered in this case:</p>
<pre lang="ts"><code>// Original code
class Foo {
  constructor(public x = 1) {}
  y = 2
}
<p>// Old output (with --loader=ts --target=es2021)<br />
class Foo {<br />
constructor(x = 1) {<br />
this.x = x;<br />
__publicField(this, &quot;y&quot;, 2);<br />
}<br />
x;<br />
}</p>
<p>// New output (with --loader=ts --target=es2021)<br />
class Foo {<br />
</code></pre></p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/blob/main/CHANGELOG.md">esbuild's
changelog</a>.</em></p>
<blockquote>
<h2>0.28.0</h2>
<ul>
<li>
<p>Add support for <code>with { type: 'text' }</code> imports (<a
href="https://redirect.github.com/evanw/esbuild/issues/4435">#4435</a>)</p>
<p>The <a href="https://github.com/tc39/proposal-import-text">import
text</a> proposal has reached stage 3 in the TC39 process, which means
that it's recommended for implementation. It has also already been
implemented by <a
href="https://docs.deno.com/examples/importing_text/">Deno</a> and <a
href="https://bun.com/docs/guides/runtime/import-html">Bun</a>. So with
this release, esbuild also adds support for it. This behaves exactly the
same as esbuild's existing <a
href="https://esbuild.github.io/content-types/#text"><code>text</code>
loader</a>. Here's an example:</p>
<pre lang="js"><code>import string from './example.txt' with { type:
'text' }
console.log(string)
</code></pre>
</li>
<li>
<p>Add integrity checks to fallback download path (<a
href="https://redirect.github.com/evanw/esbuild/issues/4343">#4343</a>)</p>
<p>Installing esbuild via npm is somewhat complicated with several
different edge cases (see <a
href="https://esbuild.github.io/getting-started/#additional-npm-flags">esbuild's
documentation</a> for details). If the regular installation of esbuild's
platform-specific package fails, esbuild's install script attempts to
download the platform-specific package itself (first with the
<code>npm</code> command, and then with a HTTP request to
<code>registry.npmjs.org</code> as a last resort).</p>
<p>This last resort path previously didn't have any integrity checks.
With this release, esbuild will now verify that the hash of the
downloaded binary matches the expected hash for the current release.
This means the hashes for all of esbuild's platform-specific binary
packages will now be embedded in the top-level <code>esbuild</code>
package. Hopefully this should work without any problems. But just in
case, this change is being done as a breaking change release.</p>
</li>
<li>
<p>Update the Go compiler from 1.25.7 to 1.26.1</p>
<p>This upgrade should not affect anything. However, there have been
some significant internal changes to the Go compiler, so esbuild could
potentially behave differently in certain edge cases:</p>
<ul>
<li>It now uses the <a
href="https://go.dev/doc/go1.26#new-garbage-collector">new garbage
collector</a> that comes with Go 1.26.</li>
<li>The Go compiler is now more aggressive with allocating memory on the
stack.</li>
<li>The executable format that the Go linker uses has undergone several
changes.</li>
<li>The WebAssembly build now unconditionally makes use of the sign
extension and non-trapping floating-point to integer conversion
instructions.</li>
</ul>
<p>You can read the <a href="https://go.dev/doc/go1.26">Go 1.26 release
notes</a> for more information.</p>
</li>
</ul>
<h2>0.27.7</h2>
<ul>
<li>
<p>Fix lowering of define semantics for TypeScript parameter properties
(<a
href="https://redirect.github.com/evanw/esbuild/issues/4421">#4421</a>)</p>
<p>The previous release incorrectly generated class fields for
TypeScript parameter properties even when the configured target
environment does not support class fields. With this release, the
generated class fields will now be correctly lowered in this case:</p>
<pre lang="ts"><code>// Original code
class Foo {
  constructor(public x = 1) {}
  y = 2
}
<p>// Old output (with --loader=ts --target=es2021)<br />
class Foo {<br />
constructor(x = 1) {<br />
this.x = x;<br />
__publicField(this, &quot;y&quot;, 2);<br />
}<br />
x;<br />
}</p>
<p></code></pre></p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/evanw/esbuild/commit/6a794dff68e6a43539f6da671e3080efdf11ca70"><code>6a794df</code></a>
publish 0.28.0 to npm</li>
<li><a
href="https://github.com/evanw/esbuild/commit/64ee0ea63b2ff303caafc9610c388dc72c882c23"><code>64ee0ea</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/4435">#4435</a>:
support <code>with { type: text }</code> imports</li>
<li><a
href="https://github.com/evanw/esbuild/commit/ef65aeeaacdb71eade186f888975b1de89574314"><code>ef65aee</code></a>
fix sort order in <code>snapshots_packagejson.txt</code></li>
<li><a
href="https://github.com/evanw/esbuild/commit/1a26a8ecbc39aaf1379c524a0274a08fbcbed655"><code>1a26a8e</code></a>
try to fix <code>test-old-ts</code>, also shuffle CI tasks</li>
<li><a
href="https://github.com/evanw/esbuild/commit/556ce6c1fc00d7c0917fbfada01ed8e5251bc510"><code>556ce6c</code></a>
use <code>''</code> instead of <code>null</code> to omit build
hashes</li>
<li><a
href="https://github.com/evanw/esbuild/commit/8e675a81a473ea69a46a69792f1386bb110dd877"><code>8e675a8</code></a>
ci: allow missing binary hashes for tests</li>
<li><a
href="https://github.com/evanw/esbuild/commit/7067763b904fe8a522fa840a4a48c5fbd4c395e0"><code>7067763</code></a>
Reapply &quot;update go 1.25.7 =&gt; 1.26.1&quot;</li>
<li><a
href="https://github.com/evanw/esbuild/commit/39473a952ab3b450d0578b698a8b8d2a02332e0d"><code>39473a9</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/4343">#4343</a>:
integrity check for binary download</li>
<li><a
href="https://github.com/evanw/esbuild/commit/2025c9ff6ab15ba6b0f9d074fd732250cc46e4a3"><code>2025c9f</code></a>
publish 0.27.7 to npm</li>
<li><a
href="https://github.com/evanw/esbuild/commit/c6b586e4904f47e8d5f783a2813660c13e2672e7"><code>c6b586e</code></a>
fix typo in <code>Makefile</code> for
<code>@esbuild/win32-x64</code></li>
<li>Additional commits viewable in <a
href="https://github.com/evanw/esbuild/compare/v0.27.3...v0.28.0">compare
view</a></li>
</ul>
</details>
<br />

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
 2026-06-03 23:32:32 -07: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