mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-17 20:09:05 +02:00
5ee9e751fbb38787c055ee793c3412ecfc89da2e
4598
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Nicky LeachandPaperclip
|
91c79d28cb |
test(e2e): retry run-lock 409 in signoff-policy agentPatch (#10386)
## Thinking Path > - Paperclip is the control plane people use to manage AI-agent work across companies > - This repository's e2e suite verifies the execution and approval paths that keep the control plane reliable > - The signoff-policy flow uses a helper that runs a heartbeat and then PATCHes the issue with that run id > - That PATCH can race the heartbeat's run-lock ownership and intermittently receive a transient 409 > - When that happens, a single-positive transition fails the shard even though the underlying behavior is only a lock contention race > - This pull request makes the helper retry the 409 path by re-reading the current lock and re-PATCHing under the winning run id > - The benefit is a stable e2e shard without weakening the negative-path assertions that protect the contract ## Linked Issues or Issue Description No public GitHub issue exists for this change. This PR addresses a flaky signoff-policy e2e transition where the helper can lose a run-lock race and receive a transient 409 while the issue is still assigned to the acting agent. ## What Changed - Added bounded retry/backoff handling in the signoff-policy `agentPatch` helper for transient run-lock 409 responses. - Re-read the issue's current lock before retrying so the helper can re-PATCH with the winning run id. - Kept the retry guarded so non-participant rejection and missing-comment 400s still surface unchanged. - Preserved the existing positive-path behavior without adding Playwright retries or weakening assertions. ## Verification - Reviewed the diff shape for a single-file change in `tests/e2e/signoff-policy.spec.ts`. - Verified the pushed commit matches the authorized submit SHA from the handoff. - Confirmed the branch contains only the expected commit and no unrelated history. - The handoff notes record deterministic harness evidence showing the pre-fix helper fails on the 409 race and the post-fix path passes. ## Risks - Low functional risk: the retry is narrowly scoped to the transient 409 lock-contention path. - If the lock semantics change server-side, the helper may need a follow-up adjustment. - The change only affects the e2e helper and does not alter production API behavior. ## Model Used OpenAI Codex (GPT-5, tool-using coding agent) ## 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>canary/v2026.728.0-canary.15 |
||
|
Devin Foley
|
dc12197cce |
fix: prevent duplicate built-in agents and self-heal reconciliation (#10223)
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Every company is auto-provisioned a set of built-in agents (e.g. the
Summarizer), and a startup reconciler keeps that set correct across
every company on boot.
> - Provisioning marks these agents with
`metadata.paperclipBuiltInAgent.key`, but nothing in the database
enforced one active agent per `(company, key)` —
`provision()`/`ensure()` did a check-then-insert with no guard.
> - Two concurrent server processes (e.g. a `tsx watch` double-boot)
could both read "no summarizer exists" and both insert, leaving a
company with duplicate built-in agents plus paired orphan pending
`hire_agent` approvals.
> - That data blemish then became a recurring outage: `findSingleAgent`
throws on >1 marked row, and because the throw escaped
`reconcileBuiltInAgentsOnStartup`'s sequential loop, **every company
after the affected one was silently skipped** on each boot — no
auto-provisioning, no default grants — until manual DB surgery.
> - This pull request closes the race at the database level and makes
reconciliation self-healing and fault-isolated.
> - The benefit is that concurrent provisioning can no longer create
duplicates, and even pre-existing duplicates are resolved automatically
instead of bricking startup reconciliation for unrelated companies.
## Linked Issues or Issue Description
- [x] I searched the GitHub PR list (open and recently closed) for
similar PRs and confirmed this is not a duplicate.
No public GitHub issue exists; describing the bug in-PR (bug-report
shape):
**What happened**
A dev instance booted with two concurrent server processes. Both ran
built-in agent provisioning for the same company at the same time, and
the check-then-insert in `provision()`/`ensure()`
(`server/src/services/built-in-agents.ts`) let both writers see "no
summarizer exists" and each create one — the company ended up with two
identical Summarizer agents (identical `paperclipBuiltInAgent` markers)
plus two paired pending `hire_agent` approvals.
From then on, **every** server boot logged:
```
ERROR: startup reconciliation of built-in agents failed
Multiple built-in agents found for summarizer (built_in_agent_duplicate_instance)
```
because `findSingleAgent` throws on >1 marked row rather than resolving
the duplicate. Worse, `reconcileBuiltInAgentsOnStartup` loops companies
sequentially and the throw escaped the loop, so every company *after*
the affected one was silently skipped on every boot.
**Expected behavior**
1. Concurrent provisioning must not create duplicate built-in agents
(there was no DB uniqueness constraint on the marker key per company).
2. Reconciliation should be resilient: if duplicates exist anyway,
self-heal (keep the oldest row, terminate the newer dupe, cancel its
orphan pending `hire_agent` approval), and never let one bad company
abort reconciliation for the rest.
**Steps to reproduce**
- Race two `provision(companyId, "summarizer")` calls for a company with
board approval for new agents enabled (or simulate a double-boot); both
insert.
- Restart the server → startup reconciliation error fires, companies
later in the loop are never reconciled.
## What Changed
**Part 1 — stop creating duplicates**
- Migration `0192_built_in_agent_unique_marker` adds a **partial unique
index** on `(company_id, metadata->'paperclipBuiltInAgent'->>'key')`
where the marker exists and `status != 'terminated'`. It first resolves
any pre-existing duplicates (keep oldest by `created_at`, terminate
newer dupes, cancel their orphan pending `hire_agent` approvals, revoke
their API keys) so the index can be created on already-affected
instances.
- `provision()`/`ensure()` now catch the losing race's `23505` unique
violation (walking the driver's wrapped cause chain) and re-resolve to
the winning row instead of surfacing the error.
**Part 2 — resilient reconciliation**
- `findSingleAgent` self-heals: keeps the oldest marked row, terminates
the newer duplicates, and cancels each one's orphan pending `hire_agent`
approval (idempotent) instead of throwing.
- `reconcileBuiltInAgentsOnStartup` isolates per-company failures in
both loops so one bad company can't abort reconciliation for the rest;
it surfaces a `companyFailures` count in the startup log.
- Adds `approvalService.cancel()` for system-initiated cancellation of
an orphan approval.
## Verification
- `pnpm --filter @paperclipai/db run check:migrations` → numbering +
safety checks pass.
- `packages/db` migration test (real embedded Postgres) — seeds
pre-index duplicate state, runs the migration, asserts dupes resolved +
index enforced: **1 passed**.
- `server` `built-in-agents.test.ts` — self-heal, concurrent races
(plain and board-gated), and startup
self-heal-without-aborting-later-companies: **34 passed**.
```
pnpm --filter @paperclipai/db exec vitest run src/built-in-agent-unique-marker-migration.test.ts
pnpm --filter @paperclipai/server exec vitest run src/__tests__/built-in-agents.test.ts
```
## Risks
- **Migration safety**: the migration mutates data (terminates duplicate
rows, cancels their orphan pending approvals, revokes their API keys)
before creating the index. It keeps the oldest row per `(company, key)`
and only touches non-terminated marked rows; the destructive step is
covered by the migration test and the safety-check baseline. On a clean
instance it is a no-op cleanup followed by `CREATE UNIQUE INDEX IF NOT
EXISTS`.
- Otherwise low risk: the unique index is partial (excludes terminated
rows, so re-provisioning after a termination stays possible), and the
conflict handling degrades gracefully to re-resolving the existing
winner.
## Model Used
Claude Opus 4.8 (`claude-opus-4-8`), 1M context window, extended
thinking, with tool use.
canary/v2026.728.0-canary.14
|
||
|
Nicky LeachandPaperclip
|
c8c2ae82a3 |
test(e2e): wait for connections fetch before asserting applications status pill (#10384)
## Thinking Path > - Paperclip relies on end-to-end tests to catch regressions in the operator UI > - The applications list status pill is rendered from more than one data fetch, so the visible label can lag behind the row itself > - A default Playwright assertion timeout can expire before the connections fetch finishes under CI load > - That creates a flaky failure without changing the underlying product behavior > - This pull request extends the two status-pill assertions to use the longer timeout already used elsewhere in the spec > - The benefit is the same UI coverage with fewer false negatives ## Linked Issues or Issue Description There is no public GitHub issue linked to this repo-local fix. This PR addresses a flaky Playwright assertion in `tests/e2e/applications-crud.spec.ts`, where the status pill can render after the default assertion timeout because it depends on the connections fetch as well as the applications fetch. ## What Changed - Increased the wait window for the two status-pill visibility assertions in `tests/e2e/applications-crud.spec.ts`. - Kept the assertions anchored to the exact expected labels (`Healthy` and `Not connected`) so the test still verifies the same behavior. ## Verification - The spec is still discovered cleanly by Playwright. - The diff stays limited to `tests/e2e/applications-crud.spec.ts`; there are no product, dependency, or lockfile changes. - The full browser-backed e2e signal remains CI for this change. ## Risks - Low risk. This only changes assertion timing in a test file and does not alter runtime product behavior. ## Model Used OpenAI Codex, GPT-5, tool-using coding agent. ## 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>canary/v2026.728.0-canary.13 |
||
|
Devin Foley
|
9f5af4ea5d |
fix(server): accept secret_ref binding objects in sandbox provider environment config (#10355)
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - Agents execute in environments; sandbox provider plugins (Daytona,
Modal, e2b, …) declare their config via a JSON schema, with credentials
marked `format: "secret-ref"`
> - The environments UI renders those fields with a secret picker that
submits `{ type: "secret_ref", secretId, version }` binding objects,
while the server-side environment config paths only understood raw
string values and bare secret-id strings
> - The binding object reached the plugin worker's
`environmentValidateConfig` untouched; plugins parse non-string config
values as absent, so saving or testing an environment with a
picker-bound secret always failed validation (e.g. "Daytona sandbox
environments require an API key in config or DAYTONA_API_KEY.", "Modal
sandbox environments require tokenId and tokenSecret.")
> - Worse, an environment first saved with raw pasted values becomes
uneditable: the stored value is a secret reference, the edit form
re-submits it as a binding object, and every subsequent save fails the
same way
> - This pull request canonicalizes binding objects to the bare secret
id before plugin validation, and teaches the persistence/runtime/probe
secret-ref resolvers to accept the object shape defensively
> - The benefit is that picker-bound secrets work for every
schema-driven sandbox provider — create, edit, and Test — with no plugin
changes required
## Linked Issues or Issue Description
Fixes #10105
The same failure reproduces with the Daytona provider: Settings →
Instance settings → Environments → New, driver sandbox, provider
daytona, bind Api Key to an existing secret via the picker → Save fails
with "Daytona sandbox environments require an API key in config or
DAYTONA_API_KEY."
## What Changed
- `server/src/services/json-schema-secret-refs.ts`: new
`parseSecretRefBindingObject()` that recognizes the `{ type:
"secret_ref", secretId, version? }` shape the secret picker submits
(version defaults to `"latest"`; malformed objects return null).
- `server/src/services/plugin-environment-driver.ts`:
`validatePluginSandboxProviderConfig()` now canonicalizes binding
objects at the driver schema's `format: "secret-ref"` paths to the bare
secret id (the persisted shape) before invoking the plugin worker's
`environmentValidateConfig`. Pinned numeric versions are rejected with a
clear 422, since sandbox provider references always resolve the latest
version — silently resolving a different version would be worse.
- `server/src/services/environment-config.ts`: the persistence, runtime,
and probe secret-ref resolvers plus `collectEnvironmentSecretRefs()`
accept the binding-object shape defensively, so any previously persisted
object-shaped refs (from providers whose validation tolerated them)
resolve instead of being silently skipped; the missing-companyId runtime
guard also now fails closed for object-shaped refs.
## Verification
- `npx vitest run server/src/__tests__/json-schema-secret-refs.test.ts
server/src/__tests__/plugin-sandbox-provider-config-validation.test.ts
server/src/__tests__/environment-routes.test.ts
server/src/__tests__/environment-config.test.ts` — 82 tests pass,
including new coverage: binding-object canonicalization before plugin
validation, pinned-version rejection, raw-string pass-through, and a
route-level create with a picker-submitted binding object persisting the
bare secret id without minting a duplicate secret.
- `npx vitest run server/src/__tests__/environment-runtime.test.ts` — 24
tests pass against embedded Postgres, including a new test that persists
an object-shaped ref and verifies runtime resolution produces the
plaintext credential for the plugin worker.
- `pnpm typecheck` in `server/` — clean.
## Risks
- Low. The canonical persisted shape (bare secret-id string) is
unchanged, so existing saved environments and lease-resume fingerprints
are unaffected; raw pasted values and bare-id strings take exactly the
same code path as before.
- New behavior only triggers where a save/probe previously failed 422
(binding objects at secret-ref paths) or where an object-shaped ref was
previously skipped silently at runtime (now resolved, or failed closed
without a companyId).
- Pinned binding versions at sandbox-provider paths are now an explicit
422 instead of an accidental validation failure; no UI submits pinned
versions today (`allowVersionSelector={false}`).
## Model Used
Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and
agentic tool use (Claude Code harness): source diagnosis, fix, and
tests.
## 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 (no
doc surface changed)
- [x] I have considered and documented any 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
|
||
|
dependabot[bot]
|
f9034ab3ca |
build(deps-dev): bump @types/node from 22.19.21 to 22.20.1 (#10304)
Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 22.19.21 to 22.20.1. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">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>canary/v2026.728.0-canary.12 |
||
|
dependabot[bot]
|
dac7e66724 |
build(deps-dev): bump storybook from 10.4.6 to 10.5.5 (#10303)
Bumps [storybook](https://github.com/storybookjs/storybook/tree/HEAD/code/core) from 10.4.6 to 10.5.5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/releases">storybook's releases</a>.</em></p> <blockquote> <h2>v10.5.5</h2> <h2>10.5.5</h2> <ul> <li>CLI: Update AI setup instructions to msw-storybook-addon v3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35512">#35512</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>Core: Upgrade `ws` to fix security advisories - <a href="https://redirect.github.com/storybookjs/storybook/pull/35584">#35584</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> <li>TanStack: Preserve explicit route ids on pathful clones - <a href="https://redirect.github.com/storybookjs/storybook/pull/35499">#35499</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>TanStack: Resolve mock redirects through Vite's resolver - <a href="https://redirect.github.com/storybookjs/storybook/pull/35501">#35501</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>TanStack: Respect routeOverrides component overrides in stories - <a href="https://redirect.github.com/storybookjs/storybook/pull/35497">#35497</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> </ul> <h2>v10.5.4</h2> <h2>10.5.4</h2> <ul> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> </ul> <h2>v10.5.3</h2> <h2>10.5.3</h2> <ul> <li>Dependencies: Upgrade TypeScript to 6.0.3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/34971">#34971</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>v10.5.2</h2> <h2>10.5.2</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>TanStack: Fix createServerFn validator mock - <a href="https://redirect.github.com/storybookjs/storybook/pull/35185">#35185</a>, thanks <a href="https://github.com/sjh9714"><code>@sjh9714</code></a>!</li> <li>TanStack: Support pathless layout routes (id-only) in story routing - <a href="https://redirect.github.com/storybookjs/storybook/pull/35465">#35465</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>Tanstack-react: Add missing Hydrate export - <a href="https://redirect.github.com/storybookjs/storybook/pull/35111">#35111</a>, thanks <a href="https://github.com/arun-357"><code>@arun-357</code></a>!</li> <li>Tanstack-react: Keep JSX-only component references during dead-code elimination - <a href="https://redirect.github.com/storybookjs/storybook/pull/35206">#35206</a>, thanks <a href="https://github.com/yatishgoel"><code>@yatishgoel</code></a>!</li> <li>Vitest: Fix coverage toggle crash on Vite 6 by clearing closed Vitest instance on restart - <a href="https://redirect.github.com/storybookjs/storybook/pull/35461">#35461</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>v10.5.1</h2> <h2>10.5.1</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>v10.5.0</h2> <h2>10.5.0</h2> <blockquote> <p><em>Foundational changes for new AI workflows</em></p> </blockquote> <p>Storybook 10.5 contains hundreds of fixes and improvements:</p> <ul> <li>⚡️ Angular-vite framework: Modern, fast dev, docs, and test (preview)</li> <li>🌈 Vitest initialGlobals: Test across themes, viewports, locales</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md">storybook's changelog</a>.</em></p> <blockquote> <h2>10.5.5</h2> <ul> <li>CLI: Update AI setup instructions to msw-storybook-addon v3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35512">#35512</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>Core: Upgrade <code>ws</code> to fix security advisories - <a href="https://redirect.github.com/storybookjs/storybook/pull/35584">#35584</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> <li>TanStack: Preserve explicit route ids on pathful clones - <a href="https://redirect.github.com/storybookjs/storybook/pull/35499">#35499</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>TanStack: Resolve mock redirects through Vite's resolver - <a href="https://redirect.github.com/storybookjs/storybook/pull/35501">#35501</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>TanStack: Respect routeOverrides component overrides in stories - <a href="https://redirect.github.com/storybookjs/storybook/pull/35497">#35497</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> </ul> <h2>10.5.4</h2> <ul> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> </ul> <h2>10.5.3</h2> <ul> <li>Dependencies: Upgrade TypeScript to 6.0.3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/34971">#34971</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>10.5.2</h2> <ul> <li>TanStack: Fix createServerFn validator mock - <a href="https://redirect.github.com/storybookjs/storybook/pull/35185">#35185</a>, thanks <a href="https://github.com/sjh9714"><code>@sjh9714</code></a>!</li> <li>TanStack: Support pathless layout routes (id-only) in story routing - <a href="https://redirect.github.com/storybookjs/storybook/pull/35465">#35465</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>Tanstack-react: Add missing Hydrate export - <a href="https://redirect.github.com/storybookjs/storybook/pull/35111">#35111</a>, thanks <a href="https://github.com/arun-357"><code>@arun-357</code></a>!</li> <li>Tanstack-react: Keep JSX-only component references during dead-code elimination - <a href="https://redirect.github.com/storybookjs/storybook/pull/35206">#35206</a>, thanks <a href="https://github.com/yatishgoel"><code>@yatishgoel</code></a>!</li> <li>Vitest: Fix coverage toggle crash on Vite 6 by clearing closed Vitest instance on restart - <a href="https://redirect.github.com/storybookjs/storybook/pull/35461">#35461</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>10.5.1</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>10.5.0</h2> <blockquote> <p><em>Foundational changes for new AI workflows</em></p> </blockquote> <p>Storybook 10.5 contains hundreds of fixes and improvements:</p> <ul> <li>⚡️ Angular-vite framework: Modern, fast dev, docs, and test (preview)</li> <li>🌈 Vitest initialGlobals: Test across themes, viewports, locales</li> <li>🤖 Agentic review: AI-curated visual changesets and search results (experimental)</li> <li>⚛️ React docgen service: Unified metadata across MCP, Docs, and Controls (experimental)</li> <li>🧑💻 Claude / Codex plugins: One-click ADE integration (experimental)</li> </ul> <!-- raw HTML omitted --> <ul> <li>A11y: Fix MDX heading anchors not keyboard accessible - <a href="https://redirect.github.com/storybookjs/storybook/pull/34368">#34368</a>, thanks <a href="https://github.com/TheSeydiCharyyev"><code>@TheSeydiCharyyev</code></a>!</li> <li>A11y: Handle lang attribute throughout preview - <a href="https://redirect.github.com/storybookjs/storybook/pull/35321">#35321</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/storybookjs/storybook/commit/05a52b7a888c6b85c3f8aa6765ed9a0a69a79e4c"><code>05a52b7</code></a> Bump version from "10.5.4" to "10.5.5" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/201e77a25c58aea0e48a3510f91d5a5d4da85860"><code>201e77a</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/35512">#35512</a> from storybookjs/yann/ai-setup-msw-v3</li> <li><a href="https://github.com/storybookjs/storybook/commit/cac1e6d595df4a8a814ea2aa5005a5dbed0e18a6"><code>cac1e6d</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/35584">#35584</a> from storybookjs/norbert/upgrade-ws-8.21</li> <li><a href="https://github.com/storybookjs/storybook/commit/9166a91fc2dac3f3b8e58ef60a81711882ef5219"><code>9166a91</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/35567">#35567</a> from ia319/bug/35566-npm-12-registry-flags</li> <li><a href="https://github.com/storybookjs/storybook/commit/3327dc44697304275e28ceaa2cd34d9bede4e333"><code>3327dc4</code></a> Bump version from "10.5.3" to "10.5.4" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/3f07eb74aec415d985efdb19eeda2e625bd2d339"><code>3f07eb7</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/35560">#35560</a> from storybookjs/norbert/fix-rn-telemetry-metadata</li> <li><a href="https://github.com/storybookjs/storybook/commit/22e36662a2c91c51bdc1204b467155ea3c870304"><code>22e3666</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/35541">#35541</a> from hxy-asdw/fix/prismjs-dark-mode-contrast-35540</li> <li><a href="https://github.com/storybookjs/storybook/commit/9ac273930a49ad33b6a331f1f36dc472f5c36054"><code>9ac2739</code></a> Bump version from "10.5.2" to "10.5.3" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/b4b00f27662caf7328330b5ab47e9b903218f43a"><code>b4b00f2</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/core/issues/34971">#34971</a> from storybookjs/valentin/upgrade-typescript-6</li> <li><a href="https://github.com/storybookjs/storybook/commit/518f711cb367d8df184be22f1fab9a218b2743df"><code>518f711</code></a> Bump version from "10.5.1" to "10.5.2" [skip ci]</li> <li>Additional commits viewable in <a href="https://github.com/storybookjs/storybook/commits/v10.5.5/code/core">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> |
||
|
dependabot[bot]
|
91e1eb43af |
build(deps): bump i18next from 26.3.1 to 26.3.6 (#10300)
Bumps [i18next](https://github.com/i18next/i18next) from 26.3.1 to 26.3.6. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/i18next/i18next/releases">i18next's releases</a>.</em></p> <blockquote> <h2>v26.3.6</h2> <ul> <li>fix: allow TypeScript 7 in the optional <code>typescript</code> peer dependency range (<code>^5 || ^6 || ^7</code>). With <code>typescript@7.0.2</code> in a project, <code>npm install</code> failed with an <code>ERESOLVE</code> peer conflict. The published types are TS7-compatible as-is: every <code>test/typescript</code> suite produces identical results under 6.0 and 7.0.2. Reported in <a href="https://redirect.github.com/i18next/react-i18next/issues/1927">react-i18next#1927</a>, thanks <a href="https://github.com/andikapradanaarif"><code>@andikapradanaarif</code></a>.</li> </ul> <h2>v26.3.5</h2> <ul> <li>fix: <code>$t()</code> nesting options blocks that span multiple lines are now parsed. <code>nest()</code> decided where the nested key ends by testing <code>match[1]</code> with <code>/{.*}/</code>, whose dot does not cross line breaks — so a <code>$t(key, { ... })</code> options object containing a newline was treated as having no options, mis-split as formatters, and the nested lookup ran without its options (placeholders stayed unresolved). The nesting regexp itself already matches newlines inside <code>$t(...)</code>; adding the <code>s</code> (dotAll) flag makes multiline options behave like the single-line form. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2440">#2440</a>).</li> <li>fix: <code>getUsedParamsDetails</code> (the <code>returnDetails: true</code> path) no longer mutates the passed <code>replace</code> object. It wrote <code>count</code> straight onto <code>options.replace</code> so the returned <code>usedParams</code> would include it — a caller reusing one <code>replace</code> object across <code>t()</code> calls then carried a stale <code>count</code> into later interpolations (e.g. a previous call's <code>count: 5</code> rendered instead of the current call's value). The details are now built from a copy; <code>usedParams</code> still includes <code>count</code>. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2441">#2441</a>).</li> <li>fix: with the default <code>skipOnVariables: true</code> + <code>escapeValue: true</code>, a <code>{{placeholder}}</code> carried inside an interpolated value now stays literal even when the value contains escapable characters. The skip logic advanced the regex <code>lastIndex</code> by the raw value length, but the escaped text written into the string is longer, so <code>lastIndex</code> landed inside the inserted value and a trailing <code>{{placeholder}}</code> in it got interpolated — leaking another in-scope variable that should have stayed literal (values without escapable characters were already skipped correctly). The advance now uses the escaped length that is actually written, and the regex-safe <code>$</code>-doubling is applied only at the <code>String.replace</code> call so it can't distort the length arithmetic. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2442">#2442</a>).</li> </ul> <h2>v26.3.4</h2> <ul> <li>fix(security): <code>deepExtend</code> (used by <code>addResourceBundle(..., deep, overwrite)</code>) no longer recurses into inherited properties. It checked key existence with the <code>in</code> operator, which walks the prototype chain, so a source key matching an inherited built-in (e.g. <code>hasOwnProperty</code>, <code>toString</code>) caused recursion into the shared <code>Object.prototype</code> function and, with <code>overwrite: true</code>, could overwrite e.g. <code>Object.prototype.hasOwnProperty.call</code> with a non-callable value — corrupting a shared built-in process-wide (DoS). Existence is now checked with <code>Object.prototype.hasOwnProperty.call</code>, so such keys are copied as plain own data instead. This complements the existing <code>__proto__</code>/<code>constructor</code> guard and is also strictly more correct for an own-property merge. Only affects applications that pass attacker-controlled data with <code>deep: true</code> and <code>overwrite: true</code>; no standard backend/integration does this. Distinct from CVE-2026-48713 / CVE-2026-48714 (different packages, <code>setPath</code> mechanism). Thanks to zx (Jace) for the responsible disclosure.</li> </ul> <h2>v26.3.3</h2> <ul> <li>fix(types): selector <code>t($ => $.arr, { returnObjects: true, context })</code> on a JSON array of <strong>heterogeneous</strong> objects now preserves each element's full shape (e.g. <code>{ transKey1: string; transKey2: string }[]</code>) instead of collapsing to a union of partial element types. Two type-level causes: (1) <code>FilterKeys</code> evaluated the whole array element type at once, so <code>keyof (A | B)</code> only saw the keys common to every element — it now distributes over the object union and filters each element independently; (2) when TypeScript merges mismatched array element types it injects phantom optional <code>undefined</code> keys (e.g. <code>transKey1_withContext?: undefined</code> on elements that don't define it), which the context-detection helpers mistook for real context variants — they now skip keys typed as <code>undefined</code>. Also adds a dedicated <code>context</code> + <code>returnObjects: true</code> selector overload using <code>const Fn</code> + <code>ReturnType<Fn></code>, so <code>Target</code> is no longer collapsed to <code>unknown</code> via <code>ApplyTarget</code>. Resolves Problem 1 of <a href="https://redirect.github.com/i18next/i18next/issues/2398">#2398</a> (Problem 2 was already fixed on master). Thanks <a href="https://github.com/sauravgupta-dotcom"><code>@sauravgupta-dotcom</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2438">#2438</a>). Fixes <a href="https://redirect.github.com/i18next/i18next/issues/2398">#2398</a>.</li> </ul> <h2>v26.3.2</h2> <ul> <li>fix: chained formatters with a parenthesised option that contains the format separator (e.g. <code>join(separator: ', ')</code>) now work at <strong>any</strong> position in the chain, not just first. Previously the comma-in-parens reassembly only repaired <code>formats[0]</code>, so <code>{{v, uppercase, join(separator: ', ')}}</code> split the <code>join(...)</code> option on the inner comma and never rejoined it, producing corrupt output. Replaced the first-position-only repair with a position-independent pass that re-joins fragments until each open paren closes. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2437">#2437</a>).</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/i18next/i18next/blob/master/CHANGELOG.md">i18next's changelog</a>.</em></p> <blockquote> <h2>26.3.6</h2> <ul> <li>fix: allow TypeScript 7 in the optional <code>typescript</code> peer dependency range (<code>^5 || ^6 || ^7</code>). With <code>typescript@7.0.2</code> in a project, <code>npm install</code> failed with an <code>ERESOLVE</code> peer conflict. The published types are TS7-compatible as-is: every <code>test/typescript</code> suite produces identical results under 6.0 and 7.0.2. Reported in <a href="https://redirect.github.com/i18next/react-i18next/issues/1927">react-i18next#1927</a>, thanks <a href="https://github.com/andikapradanaarif"><code>@andikapradanaarif</code></a>.</li> </ul> <h2>26.3.5</h2> <ul> <li>fix: <code>$t()</code> nesting options blocks that span multiple lines are now parsed. <code>nest()</code> decided where the nested key ends by testing <code>match[1]</code> with <code>/{.*}/</code>, whose dot does not cross line breaks — so a <code>$t(key, { ... })</code> options object containing a newline was treated as having no options, mis-split as formatters, and the nested lookup ran without its options (placeholders stayed unresolved). The nesting regexp itself already matches newlines inside <code>$t(...)</code>; adding the <code>s</code> (dotAll) flag makes multiline options behave like the single-line form. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2440">#2440</a>).</li> <li>fix: <code>getUsedParamsDetails</code> (the <code>returnDetails: true</code> path) no longer mutates the passed <code>replace</code> object. It wrote <code>count</code> straight onto <code>options.replace</code> so the returned <code>usedParams</code> would include it — a caller reusing one <code>replace</code> object across <code>t()</code> calls then carried a stale <code>count</code> into later interpolations (e.g. a previous call's <code>count: 5</code> rendered instead of the current call's value). The details are now built from a copy; <code>usedParams</code> still includes <code>count</code>. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2441">#2441</a>).</li> <li>fix: with the default <code>skipOnVariables: true</code> + <code>escapeValue: true</code>, a <code>{{placeholder}}</code> carried inside an interpolated value now stays literal even when the value contains escapable characters. The skip logic advanced the regex <code>lastIndex</code> by the raw value length, but the escaped text written into the string is longer, so <code>lastIndex</code> landed inside the inserted value and a trailing <code>{{placeholder}}</code> in it got interpolated — leaking another in-scope variable that should have stayed literal (values without escapable characters were already skipped correctly). The advance now uses the escaped length that is actually written, and the regex-safe <code>$</code>-doubling is applied only at the <code>String.replace</code> call so it can't distort the length arithmetic. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2442">#2442</a>).</li> </ul> <h2>26.3.4</h2> <ul> <li>fix(security): <code>deepExtend</code> (used by <code>addResourceBundle(..., deep, overwrite)</code>) no longer recurses into inherited properties. It checked key existence with the <code>in</code> operator, which walks the prototype chain, so a source key matching an inherited built-in (e.g. <code>hasOwnProperty</code>, <code>toString</code>) caused recursion into the shared <code>Object.prototype</code> function and, with <code>overwrite: true</code>, could overwrite e.g. <code>Object.prototype.hasOwnProperty.call</code> with a non-callable value — corrupting a shared built-in process-wide (DoS). Existence is now checked with <code>Object.prototype.hasOwnProperty.call</code>, so such keys are copied as plain own data instead. This complements the existing <code>__proto__</code>/<code>constructor</code> guard and is also strictly more correct for an own-property merge. Only affects applications that pass attacker-controlled data with <code>deep: true</code> and <code>overwrite: true</code>; no standard backend/integration does this. Distinct from CVE-2026-48713 / CVE-2026-48714 (different packages, <code>setPath</code> mechanism). See advisory <a href="https://github.com/i18next/i18next/security/advisories/GHSA-6jcc-5g8w-32mx">GHSA-6jcc-5g8w-32mx</a>, CVSS 5.9 (<code>CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H</code>). Thanks to zx (Jace) <a href="https://github.com/manus-use"><code>@manus-use</code></a> for the responsible disclosure.</li> </ul> <h2>26.3.3</h2> <ul> <li>fix(types): selector <code>t($ => $.arr, { returnObjects: true, context })</code> on a JSON array of <strong>heterogeneous</strong> objects now preserves each element's full shape (e.g. <code>{ transKey1: string; transKey2: string }[]</code>) instead of collapsing to a union of partial element types. Two type-level causes: (1) <code>FilterKeys</code> evaluated the whole array element type at once, so <code>keyof (A | B)</code> only saw the keys common to every element — it now distributes over the object union and filters each element independently; (2) when TypeScript merges mismatched array element types it injects phantom optional <code>undefined</code> keys (e.g. <code>transKey1_withContext?: undefined</code> on elements that don't define it), which the context-detection helpers mistook for real context variants — they now skip keys typed as <code>undefined</code>. Also adds a dedicated <code>context</code> + <code>returnObjects: true</code> selector overload using <code>const Fn</code> + <code>ReturnType<Fn></code>, so <code>Target</code> is no longer collapsed to <code>unknown</code> via <code>ApplyTarget</code>. Resolves Problem 1 of <a href="https://redirect.github.com/i18next/i18next/issues/2398">#2398</a> (Problem 2 was already fixed on master). Thanks <a href="https://github.com/sauravgupta-dotcom"><code>@sauravgupta-dotcom</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2438">#2438</a>). Fixes <a href="https://redirect.github.com/i18next/i18next/issues/2398">#2398</a>.</li> </ul> <h2>26.3.2</h2> <ul> <li>fix: chained formatters with a parenthesised option that contains the format separator (e.g. <code>join(separator: ', ')</code>) now work at <strong>any</strong> position in the chain, not just first. Previously the comma-in-parens reassembly only repaired <code>formats[0]</code>, so <code>{{v, uppercase, join(separator: ', ')}}</code> split the <code>join(...)</code> option on the inner comma and never rejoined it, producing corrupt output. Replaced the first-position-only repair with a position-independent pass that re-joins fragments until each open paren closes. Thanks <a href="https://github.com/spokodev"><code>@spokodev</code></a> (<a href="https://redirect.github.com/i18next/i18next/pull/2437">#2437</a>).</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/i18next/i18next/commit/e1c60d4dd28a16f91be7f55b3685ffcf9760619b"><code>e1c60d4</code></a> 26.3.6</li> <li><a href="https://github.com/i18next/i18next/commit/04da43e08cb799f2e6f9a5578f3674fe2ef49595"><code>04da43e</code></a> fix: allow typescript 7 in optional peerDependencies range (react-i18next#1927)</li> <li><a href="https://github.com/i18next/i18next/commit/8eed4accc6c69398e9e25f79b617249fd3f7b1ec"><code>8eed4ac</code></a> build</li> <li><a href="https://github.com/i18next/i18next/commit/573ae735682a082ad5a581dea3f2d5f517c53772"><code>573ae73</code></a> 26.3.5</li> <li><a href="https://github.com/i18next/i18next/commit/cc54b05b5cab9bf76cf66557c222c978bbb3c082"><code>cc54b05</code></a> docs(changelog): 26.3.5 — multiline $t() options, replace mutation, escaped-l...</li> <li><a href="https://github.com/i18next/i18next/commit/3180d67291a8fff10950f79660420c106c047f94"><code>3180d67</code></a> fix: skip interpolation of placeholders inside escaped values (<a href="https://redirect.github.com/i18next/i18next/issues/2442">#2442</a>)</li> <li><a href="https://github.com/i18next/i18next/commit/d16f5a2da748082155007ba0677d32b877b1102e"><code>d16f5a2</code></a> fix: stop mutating the passed replace object when returning details (<a href="https://redirect.github.com/i18next/i18next/issues/2441">#2441</a>)</li> <li><a href="https://github.com/i18next/i18next/commit/bed56c115979de52bd85c46d9b7a7b13361bf736"><code>bed56c1</code></a> fix: parse $t() nesting options block that spans multiple lines (<a href="https://redirect.github.com/i18next/i18next/issues/2440">#2440</a>)</li> <li><a href="https://github.com/i18next/i18next/commit/c19e45864f3abbbe90e30be44cc131f2248394bf"><code>c19e458</code></a> docs(changelog): link GHSA advisory for deepExtend fix</li> <li><a href="https://github.com/i18next/i18next/commit/7bb87d09f907b4395ed0825638d7d2c4356f7a89"><code>7bb87d0</code></a> docs(changelog): reference security advisory for deepExtend fix</li> <li>Additional commits viewable in <a href="https://github.com/i18next/i18next/compare/v26.3.1...v26.3.6">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>canary/v2026.728.0-canary.11 |
||
|
dependabot[bot]
|
fb680df728 |
build(deps-dev): bump @storybook/addon-a11y from 10.4.2 to 10.5.4 (#10305)
Bumps [@storybook/addon-a11y](https://github.com/storybookjs/storybook/tree/HEAD/code/addons/a11y) from 10.4.2 to 10.5.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/releases">@storybook/addon-a11y's releases</a>.</em></p> <blockquote> <h2>v10.5.4</h2> <h2>10.5.4</h2> <ul> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> </ul> <h2>v10.5.3</h2> <h2>10.5.3</h2> <ul> <li>Dependencies: Upgrade TypeScript to 6.0.3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/34971">#34971</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>v10.5.2</h2> <h2>10.5.2</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>TanStack: Fix createServerFn validator mock - <a href="https://redirect.github.com/storybookjs/storybook/pull/35185">#35185</a>, thanks <a href="https://github.com/sjh9714"><code>@sjh9714</code></a>!</li> <li>TanStack: Support pathless layout routes (id-only) in story routing - <a href="https://redirect.github.com/storybookjs/storybook/pull/35465">#35465</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>Tanstack-react: Add missing Hydrate export - <a href="https://redirect.github.com/storybookjs/storybook/pull/35111">#35111</a>, thanks <a href="https://github.com/arun-357"><code>@arun-357</code></a>!</li> <li>Tanstack-react: Keep JSX-only component references during dead-code elimination - <a href="https://redirect.github.com/storybookjs/storybook/pull/35206">#35206</a>, thanks <a href="https://github.com/yatishgoel"><code>@yatishgoel</code></a>!</li> <li>Vitest: Fix coverage toggle crash on Vite 6 by clearing closed Vitest instance on restart - <a href="https://redirect.github.com/storybookjs/storybook/pull/35461">#35461</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>v10.5.1</h2> <h2>10.5.1</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>v10.5.0</h2> <h2>10.5.0</h2> <blockquote> <p><em>Foundational changes for new AI workflows</em></p> </blockquote> <p>Storybook 10.5 contains hundreds of fixes and improvements:</p> <ul> <li>⚡️ Angular-vite framework: Modern, fast dev, docs, and test (preview)</li> <li>🌈 Vitest initialGlobals: Test across themes, viewports, locales</li> <li>🤖 Agentic review: AI-curated visual changesets and search results (experimental)</li> <li>⚛️ React docgen service: Unified metadata across MCP, Docs, and Controls (experimental)</li> <li>🧑💻 Claude / Codex plugins: One-click ADE integration (experimental)</li> </ul> <!-- raw HTML omitted --> <ul> <li>A11y: Fix MDX heading anchors not keyboard accessible - <a href="https://redirect.github.com/storybookjs/storybook/pull/34368">#34368</a>, thanks <a href="https://github.com/TheSeydiCharyyev"><code>@TheSeydiCharyyev</code></a>!</li> <li>A11y: Handle lang attribute throughout preview - <a href="https://redirect.github.com/storybookjs/storybook/pull/35321">#35321</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>A11y: Surface required args and keyboard-reachable Setup controls in ArgsTable - <a href="https://redirect.github.com/storybookjs/storybook/pull/35306">#35306</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>Addon A11y: Preserve disabled a11y rules with runOnly - <a href="https://redirect.github.com/storybookjs/storybook/pull/34649">#34649</a>, thanks <a href="https://github.com/cyphercodes"><code>@cyphercodes</code></a>!</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md">@storybook/addon-a11y's changelog</a>.</em></p> <blockquote> <h2>10.5.4</h2> <ul> <li>ReactNative: Telemetry framework detection fix - <a href="https://redirect.github.com/storybookjs/storybook/pull/35560">#35560</a>, thanks <a href="https://github.com/ndelangen"><code>@ndelangen</code></a>!</li> <li>SyntaxHighlighter: Fix PrismJS dark mode mismatch - <a href="https://redirect.github.com/storybookjs/storybook/pull/35541">#35541</a>, thanks <a href="https://github.com/hxy-asdw"><code>@hxy-asdw</code></a>!</li> </ul> <h2>10.5.3</h2> <ul> <li>Dependencies: Upgrade TypeScript to 6.0.3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/34971">#34971</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>10.5.2</h2> <ul> <li>TanStack: Fix createServerFn validator mock - <a href="https://redirect.github.com/storybookjs/storybook/pull/35185">#35185</a>, thanks <a href="https://github.com/sjh9714"><code>@sjh9714</code></a>!</li> <li>TanStack: Support pathless layout routes (id-only) in story routing - <a href="https://redirect.github.com/storybookjs/storybook/pull/35465">#35465</a>, thanks <a href="https://github.com/unpunnyfuns"><code>@unpunnyfuns</code></a>!</li> <li>Tanstack-react: Add missing Hydrate export - <a href="https://redirect.github.com/storybookjs/storybook/pull/35111">#35111</a>, thanks <a href="https://github.com/arun-357"><code>@arun-357</code></a>!</li> <li>Tanstack-react: Keep JSX-only component references during dead-code elimination - <a href="https://redirect.github.com/storybookjs/storybook/pull/35206">#35206</a>, thanks <a href="https://github.com/yatishgoel"><code>@yatishgoel</code></a>!</li> <li>Vitest: Fix coverage toggle crash on Vite 6 by clearing closed Vitest instance on restart - <a href="https://redirect.github.com/storybookjs/storybook/pull/35461">#35461</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>10.5.1</h2> <ul> <li>Angular-Vite: Drop <code>@angular/platform-browser-dynamic</code> peer dependency - <a href="https://redirect.github.com/storybookjs/storybook/pull/35457">#35457</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular-Vite: Widen TypeScript peer dependency range to support TypeScript 6 - <a href="https://redirect.github.com/storybookjs/storybook/pull/35455">#35455</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Core: Include chromatic packages in ecosystem identifier - <a href="https://redirect.github.com/storybookjs/storybook/pull/35170">#35170</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> </ul> <h2>10.5.0</h2> <blockquote> <p><em>Foundational changes for new AI workflows</em></p> </blockquote> <p>Storybook 10.5 contains hundreds of fixes and improvements:</p> <ul> <li>⚡️ Angular-vite framework: Modern, fast dev, docs, and test (preview)</li> <li>🌈 Vitest initialGlobals: Test across themes, viewports, locales</li> <li>🤖 Agentic review: AI-curated visual changesets and search results (experimental)</li> <li>⚛️ React docgen service: Unified metadata across MCP, Docs, and Controls (experimental)</li> <li>🧑💻 Claude / Codex plugins: One-click ADE integration (experimental)</li> </ul> <!-- raw HTML omitted --> <ul> <li>A11y: Fix MDX heading anchors not keyboard accessible - <a href="https://redirect.github.com/storybookjs/storybook/pull/34368">#34368</a>, thanks <a href="https://github.com/TheSeydiCharyyev"><code>@TheSeydiCharyyev</code></a>!</li> <li>A11y: Handle lang attribute throughout preview - <a href="https://redirect.github.com/storybookjs/storybook/pull/35321">#35321</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>A11y: Surface required args and keyboard-reachable Setup controls in ArgsTable - <a href="https://redirect.github.com/storybookjs/storybook/pull/35306">#35306</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>Addon A11y: Preserve disabled a11y rules with runOnly - <a href="https://redirect.github.com/storybookjs/storybook/pull/34649">#34649</a>, thanks <a href="https://github.com/cyphercodes"><code>@cyphercodes</code></a>!</li> <li>Addon Docs: DocsContent not filling available width when TOC is enabled - <a href="https://redirect.github.com/storybookjs/storybook/pull/35043">#35043</a>, thanks <a href="https://github.com/k-utsumi"><code>@k-utsumi</code></a>!</li> <li>Addon Docs: Resolve CSF4 module exports without a default export - <a href="https://redirect.github.com/storybookjs/storybook/pull/34834">#34834</a>, thanks <a href="https://github.com/TheSeydiCharyyev"><code>@TheSeydiCharyyev</code></a>!</li> <li>Addon Docs: Resolve providerImportSource to a path instead of a file:// URL - <a href="https://redirect.github.com/storybookjs/storybook/pull/34841">#34841</a>, thanks <a href="https://github.com/TheSeydiCharyyev"><code>@TheSeydiCharyyev</code></a>!</li> <li>Addon Vitest: Add an initialGlobals option to pin a project's globals - <a href="https://redirect.github.com/storybookjs/storybook/pull/35226">#35226</a>, thanks <a href="https://github.com/lifeiscontent"><code>@lifeiscontent</code></a>!</li> <li>Addon Vitest: Avoid erroring out on benign Win process exits - <a href="https://redirect.github.com/storybookjs/storybook/pull/35287">#35287</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>Addon Vitest: Fix dynamic import failure with Vitest 3 - <a href="https://redirect.github.com/storybookjs/storybook/pull/34927">#34927</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>Addon Vitest: Subscribe for run completion before triggering it - <a href="https://redirect.github.com/storybookjs/storybook/pull/35291">#35291</a>, thanks <a href="https://github.com/tsushanth"><code>@tsushanth</code></a>!</li> <li>Angular: Add versioned <code>@types/node</code> to packages installed during <code>storybook init</code> - <a href="https://redirect.github.com/storybookjs/storybook/pull/34192">#34192</a>, thanks <a href="https://github.com/copilot-swe-agent"><code>@copilot-swe-agent</code></a>!</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/storybookjs/storybook/commit/3327dc44697304275e28ceaa2cd34d9bede4e333"><code>3327dc4</code></a> Bump version from "10.5.3" to "10.5.4" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/9ac273930a49ad33b6a331f1f36dc472f5c36054"><code>9ac2739</code></a> Bump version from "10.5.2" to "10.5.3" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/b4b00f27662caf7328330b5ab47e9b903218f43a"><code>b4b00f2</code></a> Merge pull request <a href="https://github.com/storybookjs/storybook/tree/HEAD/code/addons/a11y/issues/34971">#34971</a> from storybookjs/valentin/upgrade-typescript-6</li> <li><a href="https://github.com/storybookjs/storybook/commit/518f711cb367d8df184be22f1fab9a218b2743df"><code>518f711</code></a> Bump version from "10.5.1" to "10.5.2" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/c253a0667d39899a0f7a09fa90f262f69ad4ae90"><code>c253a06</code></a> Bump version from "10.5.0" to "10.5.1" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/9dafcd22ed55947bc4c2fa1d5066b552baa0ebf4"><code>9dafcd2</code></a> Bump version from "10.5.0-beta.2" to "10.5.0" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/ad709148eb8ea2113bd326a6bc66a5c9b9f8d97c"><code>ad70914</code></a> Addon A11y: Keep nested command output while closing stdin</li> <li><a href="https://github.com/storybookjs/storybook/commit/c557fc0fb6db50c058b69fb4465f977ae786264c"><code>c557fc0</code></a> CLI: Fix silent hang in deferred addon configuration during upgrade</li> <li><a href="https://github.com/storybookjs/storybook/commit/448db85e651a09ca55f978356c4f1593f261f82a"><code>448db85</code></a> Bump version from "10.5.0-beta.1" to "10.5.0-beta.2" [skip ci]</li> <li><a href="https://github.com/storybookjs/storybook/commit/a4ce9790a783d8e7720e9de980a08576de9555db"><code>a4ce979</code></a> Bump version from "10.5.0-beta.0" to "10.5.0-beta.1" [skip ci]</li> <li>Additional commits viewable in <a href="https://github.com/storybookjs/storybook/commits/v10.5.4/code/addons/a11y">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
00b43a7446 |
build(deps): bump @tanstack/react-query from 5.101.2 to 5.101.4 (#10307)
Bumps [@tanstack/react-query](https://github.com/TanStack/query/tree/HEAD/packages/react-query) from 5.101.2 to 5.101.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/TanStack/query/releases">@tanstack/react-query's releases</a>.</em></p> <blockquote> <h2><code>@tanstack/react-query-devtools</code><a href="https://github.com/5"><code>@5</code></a>.101.4</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-devtools</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> </ul> </li> </ul> <h2><code>@tanstack/react-query-next-experimental</code><a href="https://github.com/5"><code>@5</code></a>.101.4</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> </ul> </li> </ul> <h2><code>@tanstack/react-query-persist-client</code><a href="https://github.com/5"><code>@5</code></a>.101.4</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-persist-client-core</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> </ul> </li> </ul> <h2><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.4</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-core</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> </ul> </li> </ul> <h2><code>@tanstack/react-query-devtools</code><a href="https://github.com/5"><code>@5</code></a>.101.3</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-devtools</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> </ul> </li> </ul> <h2><code>@tanstack/react-query-next-experimental</code><a href="https://github.com/5"><code>@5</code></a>.101.3</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> </ul> </li> </ul> <h2><code>@tanstack/react-query-persist-client</code><a href="https://github.com/5"><code>@5</code></a>.101.3</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-persist-client-core</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> <li><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> </ul> </li> </ul> <h2><code>@tanstack/react-query</code><a href="https://github.com/5"><code>@5</code></a>.101.3</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies [<a href="https://github.com/TanStack/query/commit/7e3c822a10896f41a8f1031c16b85096277af677"><code>7e3c822</code></a>]:</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/TanStack/query/blob/main/packages/react-query/CHANGELOG.md">@tanstack/react-query's changelog</a>.</em></p> <blockquote> <h2>5.101.4</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies []: <ul> <li><code>@tanstack/query-core</code><a href="https://github.com/5"><code>@5</code></a>.101.4</li> </ul> </li> </ul> <h2>5.101.3</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies [<a href="https://github.com/TanStack/query/commit/7e3c822a10896f41a8f1031c16b85096277af677"><code>7e3c822</code></a>]: <ul> <li><code>@tanstack/query-core</code><a href="https://github.com/5"><code>@5</code></a>.101.3</li> </ul> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/TanStack/query/commit/86bb8a6fb2c7f15c74ff50afba053d778e6edc23"><code>86bb8a6</code></a> ci: Version Packages (<a href="https://github.com/TanStack/query/tree/HEAD/packages/react-query/issues/11094">#11094</a>)</li> <li><a href="https://github.com/TanStack/query/commit/181ea826cb5b5f722a774525046d8f4e105dd6bb"><code>181ea82</code></a> ci: Version Packages (<a href="https://github.com/TanStack/query/tree/HEAD/packages/react-query/issues/11089">#11089</a>)</li> <li><a href="https://github.com/TanStack/query/commit/6d55b0759b4722b888fa516b1bb86c0a56ea47a2"><code>6d55b07</code></a> test({react,preact}-query): use the '.then()' convention consistently (<a href="https://github.com/TanStack/query/tree/HEAD/packages/react-query/issues/11085">#11085</a>)</li> <li><a href="https://github.com/TanStack/query/commit/44f38df5deaf72d8d74bc62b620dffed43fdbc05"><code>44f38df</code></a> test({react,preact,solid}-query/useInfiniteQuery): inline the shared 'fetchIt...</li> <li><a href="https://github.com/TanStack/query/commit/d1558c1491629b36661e0a166e1091bb4a256daa"><code>d1558c1</code></a> test({react,preact}-query/usePrefetchQuery): inline the 'generateQueryFn' fac...</li> <li><a href="https://github.com/TanStack/query/commit/99690d18b7937f217d3744b1c2ac78cc47caeaa7"><code>99690d1</code></a> test({react,preact}-query/usePrefetchInfiniteQuery): inline single-use helper...</li> <li><a href="https://github.com/TanStack/query/commit/10770f0720dacae3a26701a747e33abd6bafbf8a"><code>10770f0</code></a> test({react,preact}-query/usePrefetchInfiniteQuery): inline the shared 'Suspe...</li> <li><a href="https://github.com/TanStack/query/commit/dbd5a86e95284387bc3f172208bc52c0053a1bb2"><code>dbd5a86</code></a> test({react,preact}-query/usePrefetchQuery): inline the shared 'Suspended' co...</li> <li><a href="https://github.com/TanStack/query/commit/b955f60d7965cc521df6ee8b1ce91b3d0e8c046d"><code>b955f60</code></a> test({react,preact}-query/useSuspenseQuery): assert the 'loading' fallback is...</li> <li><a href="https://github.com/TanStack/query/commit/b9c657e20b1ac1078ab265de8fc691aec192e143"><code>b9c657e</code></a> test({react,preact}-query/usePrefetchQuery): assert the 'Loading...' fallback...</li> <li>Additional commits viewable in <a href="https://github.com/TanStack/query/commits/@tanstack/react-query@5.101.4/packages/react-query">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
e95045905b |
build(deps): bump better-auth from 1.6.23 to 1.6.25 (#10306)
Bumps [better-auth](https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth) from 1.6.23 to 1.6.25. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/better-auth/better-auth/releases">better-auth's releases</a>.</em></p> <blockquote> <h2>v1.6.25</h2> <h2><code>better-auth</code></h2> <h3>Bug Fixes</h3> <ul> <li>Fixed Apple OAuth not sending the PKCE code challenge during authorization, causing token exchange failures (<a href="https://redirect.github.com/better-auth/better-auth/pull/10294">#10294</a>)</li> <li>Fixed Google One Tap creating new users when sign-up was disabled on the Google provider (<a href="https://redirect.github.com/better-auth/better-auth/pull/10479">#10479</a>)</li> <li>Fixed <code>$fetch</code> and <code>$store</code> not being exposed on the Solid client (<a href="https://redirect.github.com/better-auth/better-auth/pull/10444">#10444</a>)</li> <li>Fixed internal adapter queries being routed to the wrong table when a built-in table's <code>modelName</code> was set to another table's schema key (e.g. <code>user.modelName = "account"</code>).</li> </ul> <p>For detailed changes, see <a href="https://github.com/better-auth/better-auth/blob/07a646ea190167370fbbb60a0fa2c3be3bec5522/packages/better-auth/CHANGELOG.md"><code>CHANGELOG</code></a></p> <h2>Contributors</h2> <p>Thanks to everyone who contributed to this release:</p> <p><a href="https://github.com/birkskyum"><code>@birkskyum</code></a>, <a href="https://github.com/jsj"><code>@jsj</code></a>, <a href="https://github.com/krish-vachhani"><code>@krish-vachhani</code></a></p> <p><strong>Full changelog:</strong> <a href="https://github.com/better-auth/better-auth/compare/v1.6.24...v1.6.25"><code>v1.6.24...v1.6.25</code></a></p> <h2>v1.6.24</h2> <h2><code>better-auth</code></h2> <h3>Features</h3> <ul> <li>Added request context (<code>ctx</code>) as a third argument to <code>verifyIdToken</code>, enabling custom ID token verifiers to read request headers (<a href="https://redirect.github.com/better-auth/better-auth/pull/10376">#10376</a>)</li> <li>Added <code>beforeStoreCookie</code> option to the last-login-method plugin for GDPR compliance (<a href="https://redirect.github.com/better-auth/better-auth/pull/5753">#5753</a>)</li> </ul> <h3>Bug Fixes</h3> <ul> <li>Replaced flaky MongoDB where-coercion integration test with a direct unit test for more reliable test runs (<a href="https://redirect.github.com/better-auth/better-auth/pull/10369">#10369</a>)</li> <li>Fixed the <code>get-session</code> endpoint to include <code>no-store</code> cache control headers, preventing stale session data from being served (<a href="https://redirect.github.com/better-auth/better-auth/pull/10222">#10222</a>)</li> <li>Fixed SQLite migration diffs to recognize <code>BIGINT</code> as a valid number type, preventing spurious pending changes on rate limiter columns (<a href="https://redirect.github.com/better-auth/better-auth/pull/10316">#10316</a>)</li> <li>Fixed auth requests failing when request cloning throws an error inside verification callbacks (<a href="https://redirect.github.com/better-auth/better-auth/pull/10336">#10336</a>)</li> <li>Fixed <code>useSession({ throw: true })</code> incorrectly excluding <code>null</code> from its <code>data</code> type (<a href="https://redirect.github.com/better-auth/better-auth/pull/9787">#9787</a>)</li> <li>Fixed auth query revalidation and signal listeners not being restored after a client component remounts (<a href="https://redirect.github.com/better-auth/better-auth/pull/10379">#10379</a>)</li> <li>Fixed the <code>CookieAttributes</code> index signature type to be more precise (<a href="https://redirect.github.com/better-auth/better-auth/pull/10442">#10442</a>)</li> <li>Fixed silent misrouting of adapter queries when <code>user.modelName</code> was set to a value that collides with another schema key (<a href="https://redirect.github.com/better-auth/better-auth/pull/10235">#10235</a>)</li> <li>Fixed Kysely migration generation producing duplicate indexes for fields marked both <code>unique</code> and <code>index</code> (<a href="https://redirect.github.com/better-auth/better-auth/pull/10357">#10357</a>)</li> <li>Fixed magic-link and email-OTP send endpoints to validate the <code>Origin</code> header on cookieless requests, preventing cross-origin abuse (<a href="https://redirect.github.com/better-auth/better-auth/pull/10368">#10368</a>)</li> <li>Fixed remote MCP auth 401 challenge headers being hidden from browser clients due to missing CORS exposure (<a href="https://redirect.github.com/better-auth/better-auth/pull/10290">#10290</a>)</li> <li>Fixed OpenAPI schema to include plugin user fields (such as <code>username</code> and <code>displayUsername</code>) in <code>/sign-up/email</code> and <code>/update-user</code> request bodies (<a href="https://redirect.github.com/better-auth/better-auth/pull/10453">#10453</a>)</li> <li>Fixed <code>organization.listMembers</code> failing with "User not found for member" for organizations with more than ~100 members (<a href="https://redirect.github.com/better-auth/better-auth/pull/10342">#10342</a>)</li> <li>Fixed organization invitations to use database-generated IDs when <code>advanced.database.generateId</code> is configured, matching the behavior of other models (<a href="https://redirect.github.com/better-auth/better-auth/pull/10040">#10040</a>)</li> <li>Fixed <code>getDefaultModelName</code> to prefer exact schema key matches over <code>modelName</code> aliases, preventing adapter queries from being misrouted when a built-in table's name collides with another schema key</li> </ul> <p>For detailed changes, see <a href="https://github.com/better-auth/better-auth/blob/9a661c7b7abceaa81123b2c56757ee24f3ad2ed6/packages/better-auth/CHANGELOG.md"><code>CHANGELOG</code></a></p> <h2><code>auth</code></h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/better-auth/better-auth/blob/main/packages/better-auth/CHANGELOG.md">better-auth's changelog</a>.</em></p> <blockquote> <h2>1.6.25</h2> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10479">#10479</a> <a href="https://github.com/better-auth/better-auth/commit/5124c3487903e96223bb3f54347724bb0204bb95"><code>5124c34</code></a> Thanks <a href="https://github.com/krish-vachhani"><code>@krish-vachhani</code></a>! - Prevent Google One Tap from creating new users when sign-up is disabled for the Google provider.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10444">#10444</a> <a href="https://github.com/better-auth/better-auth/commit/743935991f9991e8243d6c3d14773b9cfca462e8"><code>7439359</code></a> Thanks <a href="https://github.com/birkskyum"><code>@birkskyum</code></a>! - Expose the real <code>$fetch</code> instance and <code>$store</code> atoms from the Solid client instead of resolving them as dynamic API routes.</p> </li> <li> <p>Updated dependencies [<a href="https://github.com/better-auth/better-auth/commit/0ffd1fb28d44a8266d62791cd4c97e263444d03b"><code>0ffd1fb</code></a>]:</p> <ul> <li><code>@better-auth/core</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/drizzle-adapter</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/kysely-adapter</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/memory-adapter</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/mongo-adapter</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/prisma-adapter</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> <li><code>@better-auth/telemetry</code><a href="https://github.com/1"><code>@1</code></a>.6.25</li> </ul> </li> </ul> <h2>1.6.24</h2> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10235">#10235</a> <a href="https://github.com/better-auth/better-auth/commit/03dc5a046f536994950800ea557b8e2e2e0cdfdd"><code>03dc5a0</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - Fixes silent foreign-key and adapter-join misrouting when a user remaps a built-in model name to a string that collides with another schema key</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10357">#10357</a> <a href="https://github.com/better-auth/better-auth/commit/750894037639c4158472cc1d4994b0e07bf1f59a"><code>7508940</code></a> Thanks <a href="https://github.com/c-nicol"><code>@c-nicol</code></a>! - Fixes Kysely migration generation for new-table fields that are both unique: true and index: true.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10342">#10342</a> <a href="https://github.com/better-auth/better-auth/commit/bae71988ab79aeb4f19f245ceabac9eca8706a50"><code>bae7198</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - Fix <code>organization.listMembers</code> failing with "User not found for member" for orgs with more than ~100 members by applying the same membership limit to the users query.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10336">#10336</a> <a href="https://github.com/better-auth/better-auth/commit/ef4d27360cec8a0bc11a94e135ea4a3dd32b1969"><code>ef4d273</code></a> Thanks <a href="https://github.com/Tushar-Khandelwal-2004"><code>@Tushar-Khandelwal-2004</code></a>! - Prevent verification callbacks from failing auth requests when cloning the request throws.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10333">#10333</a> <a href="https://github.com/better-auth/better-auth/commit/99dbdd7ea98740d11689394220a718dfb9579276"><code>99dbdd7</code></a> Thanks <a href="https://github.com/c-nicol"><code>@c-nicol</code></a>! - Fixes Drizzle schema generation for fields that are both unique: true and index: true.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10368">#10368</a> <a href="https://github.com/better-auth/better-auth/commit/086ca91f51dd8158aff6cbf54c4f9c7ce220914d"><code>086ca91</code></a> Thanks <a href="https://github.com/gaurav0107"><code>@gaurav0107</code></a>! - Force-validate the request <code>Origin</code> on the magic-link (<code>/sign-in/magic-link</code>) and email-otp (<code>/email-otp/send-verification-otp</code>) send endpoints, including cookieless requests, to match the built-in <code>/sign-in/email</code> and <code>/sign-up/email</code> routes. A cookieless cross-origin POST can no longer trigger a magic-link or verification-OTP email to an arbitrary address. Cookieless requests that carry no <code>Origin</code> (server-to-server) are unaffected.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10290">#10290</a> <a href="https://github.com/better-auth/better-auth/commit/8f2dedd89301da9fb52c1a64df6a9683f9be55fd"><code>8f2dedd</code></a> Thanks <a href="https://github.com/GautamBytes"><code>@GautamBytes</code></a>! - Expose the remote MCP auth client's 401 challenge headers to browser clients using CORS.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10453">#10453</a> <a href="https://github.com/better-auth/better-auth/commit/4e685eef420b5576913b9803b58c7e7ee7342203"><code>4e685ee</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - OpenAPI now includes <code>user.additionalFields</code> and plugin user schema fields (e.g. username plugin <code>username</code> / <code>displayUsername</code>) on <code>/sign-up/email</code> and <code>/update-user</code> request bodies.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10190">#10190</a> <a href="https://github.com/better-auth/better-auth/commit/3bf0e4981e025ba9af684013a27b0102a04f7c56"><code>3bf0e49</code></a> Thanks <a href="https://github.com/gaurav-init"><code>@gaurav-init</code></a>! - Pass the endpoint context as the second argument to <code>beforeDeleteOrganization</code> and <code>afterDeleteOrganization</code> hooks in the organization plugin, matching the signature shown in the docs and the existing <code>databaseHooks</code> pattern. The Stripe plugin's <code>beforeDeleteOrganization</code> wrapper now forwards the context to user-supplied hooks instead of dropping it.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10040">#10040</a> <a href="https://github.com/better-auth/better-auth/commit/f59a0ee7895a024ddd4c5c387344173888e17be4"><code>f59a0ee</code></a> Thanks <a href="https://github.com/shiminshen"><code>@shiminshen</code></a>! - Organization invitations now let the database generate their <code>id</code> when ID generation is delegated to the database (e.g. <code>advanced.database.generateId: "uuid"</code> with a UUID-capable adapter such as Postgres), matching every other model. Previously <code>createInvitation</code> always generated the invitation <code>id</code> in application code, so invitation rows received an app-generated value instead of a database-generated one while organizations, members and teams correctly deferred to the database (<a href="https://redirect.github.com/better-auth/better-auth/issues/10024">better-auth/better-auth#10024</a>). A caller-provided id (e.g. via <code>beforeCreateInvitation</code>) is still honored.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10302">#10302</a> <a href="https://github.com/better-auth/better-auth/commit/0f2cc1b33b77850948dac4d889e5f46bba41e8d5"><code>0f2cc1b</code></a> Thanks <a href="https://github.com/momomuchu"><code>@momomuchu</code></a>! - Prefer exact schema-key matches over <code>modelName</code> aliases in <code>getDefaultModelName</code>, so remapping a built-in table onto another table's schema key (e.g. <code>user.modelName = "account"</code>) does not reroute internal adapter queries to the wrong table.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/9787">#9787</a> <a href="https://github.com/better-auth/better-auth/commit/ae781091186f321b4e4ec9e84f64b6e4d5ea1043"><code>ae78109</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - Fixes an issue where <code>useSession({ throw: true })</code> incorrectly excluded <code>null</code> from its <code>data</code> type.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10222">#10222</a> <a href="https://github.com/better-auth/better-auth/commit/46d2bf02c98902da7b344753372d48cfe0e5ebb3"><code>46d2bf0</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - fix: add no-store cache-control headers to get-session route</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10316">#10316</a> <a href="https://github.com/better-auth/better-auth/commit/29a373eaf1778820061a9380c29831c2de2ce704"><code>29a373e</code></a> Thanks <a href="https://github.com/vinay-oppuri"><code>@vinay-oppuri</code></a>! - Recognize SQLite <code>BIGINT</code> as a valid number type in migration diffs so database-backed rate limiter columns like <code>lastRequest</code> no longer report spurious pending changes on every run.</p> </li> <li> <p><a href="https://redirect.github.com/better-auth/better-auth/pull/10379">#10379</a> <a href="https://github.com/better-auth/better-auth/commit/f6d18fa8f79b9323e10b50f72e2b1a088844e4bb"><code>f6d18fa</code></a> Thanks <a href="https://github.com/ping-maxwell"><code>@ping-maxwell</code></a>! - fix(client): restore auth query revalidation and signal listeners after remount</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/better-auth/better-auth/commit/07a646ea190167370fbbb60a0fa2c3be3bec5522"><code>07a646e</code></a> chore: release v1.6.25 (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10491">#10491</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/743935991f9991e8243d6c3d14773b9cfca462e8"><code>7439359</code></a> fix(solid): expose $fetch and $store on the solid client (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10444">#10444</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/dac701c94bcd777e7cb124570d644f8b4a7981a5"><code>dac701c</code></a> chore(deps): bump next from 16.2.6 to 16.2.11 (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10493">#10493</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/5124c3487903e96223bb3f54347724bb0204bb95"><code>5124c34</code></a> fix(one-tap): enforce google provider signup restrictions (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10479">#10479</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/9a661c7b7abceaa81123b2c56757ee24f3ad2ed6"><code>9a661c7</code></a> chore: release v1.6.24 (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10323">#10323</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/4e685eef420b5576913b9803b58c7e7ee7342203"><code>4e685ee</code></a> fix(open-api): include plugin user fields on sign-up/update bodies (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10453">#10453</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/d3ce7823324ba64efd423895b1c122d85c6d7663"><code>d3ce782</code></a> fix(cookies): tighten CookieAttributes index signature type (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10441">#10441</a>) (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10442">#10442</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/ae781091186f321b4e4ec9e84f64b6e4d5ea1043"><code>ae78109</code></a> fix(client): preserve null in useSession().data type with throw:true (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/9787">#9787</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/f6d18fa8f79b9323e10b50f72e2b1a088844e4bb"><code>f6d18fa</code></a> fix(client): restore auth query lifecycle after remount (<a href="https://github.com/better-auth/better-auth/tree/HEAD/packages/better-auth/issues/10379">#10379</a>)</li> <li><a href="https://github.com/better-auth/better-auth/commit/086ca91f51dd8158aff6cbf54c4f9c7ce220914d"><code>086ca91</code></a> fix(magic-link, email-otp): force-validate Origin on cookieless send endpoint...</li> <li>Additional commits viewable in <a href="https://github.com/better-auth/better-auth/commits/v1.6.25/packages/better-auth">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
0a6532175c |
build(deps): bump react-resizable-panels from 4.12.1 to 4.12.2 (#10301)
Bumps [react-resizable-panels](https://github.com/bvaughn/react-resizable-panels) from 4.12.1 to 4.12.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/bvaughn/react-resizable-panels/blob/main/CHANGELOG.md">react-resizable-panels's changelog</a>.</em></p> <blockquote> <h2>4.12.2</h2> <ul> <li><a href="https://redirect.github.com/bvaughn/react-resizable-panels/issues/726">726</a>: Updated inline documentation to clarify size units.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/bvaughn/react-resizable-panels/commit/a1eeb7aefdb024bb5879a323218e0ac05f77f28e"><code>a1eeb7a</code></a> 4.12.1 -> 4.12.2</li> <li>See full diff in <a href="https://github.com/bvaughn/react-resizable-panels/compare/4.12.1...4.12.2">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
4881f548be |
build(deps): bump @cursor/sdk from 1.0.19 to 1.0.24 (#10298)
Bumps [@cursor/sdk](https://github.com/cursor/cursor) from 1.0.19 to 1.0.24. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/cursor/cursor/commits">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~luist18">luist18</a>, a new releaser for <code>@cursor/sdk</code> since your current version.</p> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>canary/v2026.728.0-canary.10 |
||
|
|
9ff7e1caf3 |
perf(adapter-utils): content-hash-skip process-session remote script write + lock inbound round-trip count (#10377)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The sandbox runtime depends on efficiently staging files into remote environments > - The process-session bridge was rewriting a static remote script on every start, even when the remote copy already matched > - That caused unnecessary round trips and made the startup path noisier than it needed to be > - This pull request adds a hash-skip path for the process-session script write and keeps the existing bridge-entrypoint hash gate on the same helper > - It also locks in the reduced inbound round-trip count so the collapse from the prior PR cannot silently regress > - The benefit is fewer remote execs on warm starts and a stronger guard against performance regressions ## Linked Issues or Issue Description - Refs: https://github.com/paperclipai/paperclip/pull/10354 ### Feature request-style description **Subsystem affected** - Cross-cutting (packages/adapter-utils and sandbox staging helpers) **Problem or motivation** - The process-session bootstrap path was rewriting a static remote script on every start even when the remote file already matched the host content. - That added avoidable remote execs and latency to warm starts. - The inbound staging collapse from the previous PR also needed a regression lock so it could not silently drift back to extra round trips. **Proposed solution** - Route the process-session remote script upload through the existing hash-skip helper used by the sandbox callback bridge entrypoint. - Keep the bridge-entrypoint behavior unchanged by delegating it to the same helper. - Add a regression test that asserts the inbound staging path still collapses to the expected round-trip count. **Alternatives considered** - Keep the existing unconditional write path and accept the extra execs on warm starts. Rejected because it preserves avoidable overhead. - Add a second specialized helper just for process-session scripts. Rejected because the bridge-entrypoint logic already solved the same problem and should stay aligned. **Roadmap alignment** - This fits the roadmap items around cloud/sandbox agents and enforced outcomes by reducing bootstrap waste and preventing performance regressions. - It does not introduce new product surface area, telemetry, or user-facing workflow changes. **Additional context** - The implementation preserves the existing upload/verify/rename behavior when the remote content differs and only skips the write when the hash already matches. - PR #10354 collapsed the inbound staging path; this PR preserves that win. ## What Changed - Added a shared hash-skip helper for remote text-file synchronization so unchanged content skips the write path after a single remote hash check. - Switched the process-session remote script upload to use that helper, preserving the existing write/verify/rename behavior when the remote content differs. - Refactored the sandbox callback bridge entrypoint sync to use the same helper without changing its observable behavior. - Added a mocked-native-runner regression test that locks the inbound staging path to one `client.syncIn` round-trip per step and zero direct write/run execs. ## Verification - `tsc --noEmit` - `pnpm --filter @paperclipai/adapter-utils exec vitest run` - Full adapter-utils vitest sweep: 338 passed / 4 skipped ## Risks - Low risk: the helper changes when a write occurs, not the script contents or the remote execution surface. - A hash-check failure now fails loudly instead of silently rewriting, which is safer but could surface provider-side issues earlier than before. - The regression test is intentionally specific to the current collapsed staging path, so future architectural changes will need test updates. ## Model Used OpenAI Codex (GPT-5, tool-using coding agent) ## 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: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
Nicky Leach
|
341993ebae | feat(sandbox-runtime): route all inbound staging through client.syncIn (Codex home -> native uploadFiles; delete usesCustomProvision gate) (#10354) canary/v2026.728.0-canary.9 | ||
|
Nicky LeachandPaperclip
|
7797995038 |
perf(plugin-daytona): opt-in no-profile fast path for default-PATH execs (#10352)
## Thinking Path > - Paperclip is the control plane for autonomous AI companies > - The Daytona adapter turns tasks into shell commands and manages execution overhead > - Many short-lived exec calls still pay for login-shell profile sourcing even when the binary already resolves on the sandbox default PATH > - That extra startup work adds latency on the hot path for repeated command execution > - This pull request adds an opt-in fast path that skips profile sourcing only when the caller explicitly requests it and the command does not need shell initialization > - The benefit is lower per-call latency for eligible commands without changing the conservative default behavior for commands that need the profile ## Linked Issues or Issue Description This change does not reference a public GitHub issue. It follows the same Daytona startup-speed work as merged PR #10335 and narrows the execution path for eligible commands while keeping the default login-shell behavior intact. ## What Changed - Added an optional `noProfile` flag to `PluginEnvironmentExecuteParams`. - Refactored Daytona login-shell script assembly so the profile and nvm sourcing block is omitted only on the explicit fast path. - Preserved environment prefixing, `cd`, shell quoting, `NONINTERACTIVE_GIT_ENV`, stdin handling, and `durationMs` behavior on both paths. - Added regression tests for the fast path omission, the preserved execution parameters, and the default profile-sourcing path. ## Verification - `pnpm --filter @paperclipai/sandbox-provider-daytona exec vitest run src/plugin.test.ts` - `pnpm --filter @paperclipai/plugin-sdk tsc --noEmit` - Reverted the guard locally to confirm the two behavior tests fail again, then restored the change. ## Risks - If a caller opts into `noProfile` for a command that depends on shell initialization, the command can fail to resolve its binary. - The API comment and opt-in design keep that risk narrow; the default path remains unchanged. ## Model Used OpenAI GPT-5 (Codex tool-using coding agent) ## 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>canary/v2026.728.0-canary.8 |
||
|
Nicky LeachandPaperclip
|
0ccba45e4d |
feat(sandbox-providers): native providers honor postUploadCommands (Daytona executes; Kubernetes executes) (#10347)
## Thinking Path > - Paperclip is the control plane for autonomous AI companies, so runtime handoffs have to preserve the exact behavior an agent asked for. > - The sandbox-provider layer is where uploaded files and follow-up commands become a real in-sandbox operation. > - The provider-delegable sync-in seam already exists from the prior PR; without this follow-up, native providers can still accept command-bearing uploads and silently drop the commands. > - That is a fail-open gap for native sandbox providers, because the file transfer succeeds while the intended post-upload work never runs. > - This pull request teaches Daytona and Kubernetes to execute `postUploadCommands` in order, inside the sandbox, after the files land. > - The benefit is consistent and safer sync semantics: native providers either run the commands as requested or fail fast instead of pretending the operation completed fully. ## Linked Issues or Issue Description This PR builds on the previously merged provider-delegable sync-in seam and closes the remaining gap for native providers that still dropped `postUploadCommands`. Problem: - A sync operation could include ordered `postUploadCommands`, but a native provider could finish the file upload and skip the commands entirely. - That creates fail-open behavior for command-bearing uploads, especially when the caller relies on the provider to execute the follow-up action in the sandbox. Proposed fix: - Execute `postUploadCommands` inside the sandbox after file placement. - Preserve the provided command order. - Fail fast on the first non-zero exit or timeout. - Keep command execution verbatim and confine any provided `cwd` under the workspace root. Related public PR: - Refs: #10340 ## What Changed - Daytona `performSyncIn` now executes ordered `postUploadCommands` through the existing `executeCommand` seam. - Kubernetes `performSyncIn` now executes ordered `postUploadCommands` through its streaming pod exec path. - Added workspace confinement for provided `cwd` values and defaulted missing `cwd` to the remote root. - Added tests covering the new post-upload command execution behavior in both provider packages. ## Verification - Latest validation recorded on the handoff branch: `@paperclipai/plugin-sdk` and `@paperclipai/plugin-kubernetes` typechecks passed. - Daytona Vitest: `63/63` passing in `plugin.test.ts`. - Kubernetes Vitest: `195/195` passing, including `file-sync.test.ts`. - `git log --oneline origin/master..HEAD` showed a single expected commit on the branch. ## Risks - Command execution semantics are stricter now, so malformed commands or a bad `cwd` will fail the sync instead of being ignored. - The change makes provider behavior more explicit, which can surface previously hidden failures in callers that assumed commands were optional. - Timeout behavior may differ slightly between providers, so the failure mode is intentionally fail-fast. ## Model Used OpenAI Codex, GPT-5-based coding agent with 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 - [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>canary/v2026.728.0-canary.7 |
||
|
DottaandPaperclip
|
1cd09ed555 |
perf(heartbeat): reuse task sessions for issue-scoped timer wakes and bound control-plane write retries (#10350)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents make progress in heartbeats: the server wakes an agent session, it does a slice of work on an issue, records a disposition, and exits > - Benchmarking identical coding tasks run as Paperclip-orchestrated agent pairs vs invoking the same agent harness directly measured a 1.8–2.2× wall-clock slowdown for the Paperclip pairs, dominated by per-heartbeat orchestration overhead rather than model time > - Two contributors stood out: (1) since PF-4 (#4838) every `heartbeat_timer` wake starts a brand-new task session, so continuation work on a specific issue repays the full session-start and re-orientation cost on every heartbeat; (2) in degraded environments agents burn many tool calls retrying the same failing control-plane write before giving up > - This pull request reuses the task session for issue-scoped timer wakes (keeping the PF-4 fresh-session rule only for unscoped exploratory wakes, which were the original context-bloat case) and adds a bounded-retry rule to the wake prompt and core skill: after 2 consecutive failures of the same control-plane write, stop retrying it for the rest of the heartbeat and rely on the adapter/runtime status channel > - The benefit is materially less wall-clock and token overhead per heartbeat while preserving the context-bloat protection PF-4 was added for ## Linked Issues or Issue Description Refs #4838 (merged PF-4 change whose reset rule this refines), Refs #5287, Refs #1907 (related timer-heartbeat session work). No public GitHub issue exists for the slowdown itself; bug-report fields: - **What happened:** Agent pairs orchestrated through Paperclip heartbeats complete identical task sets 1.8–2.2× slower (wall-clock) than the same harness invoked directly. Profiling attributed the gap to per-heartbeat orchestration overhead: every timer wake discards the task session (full session start + re-orientation), and in degraded environments agents repeatedly retry the same failing control-plane write. - **Expected behavior:** Heartbeat orchestration should add minimal wall-clock overhead on top of the underlying harness; issue-scoped continuation work should not pay a fresh-session tax each interval. - **Steps to reproduce:** Run a fixed benchmark task set once through Paperclip issue heartbeats and once via direct harness invocation with the same model/config; compare wall-clock totals. - **Version/commit:** master @canary/v2026.728.0-canary.6 |
||
|
Nicky LeachandPaperclip
|
3d23c3b2c3 |
perf(plugin-daytona): cache the started sandbox handle per lease (#10335)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Daytona sandbox adapter spends time on repeated per-exec sandbox lookups during a lease > - That repeated lookup is pure overhead once the started sandbox handle is already known and trusted for the lease > - The adapter still needs strict isolation and fail-closed behavior because the handle is an authenticated compute object, not an inert value > - This pull request memoizes the started sandbox handle per lease in a process-scoped cache, and now advances freshness only after successful reuse so failed commands cannot suppress stale-handle refreshes > - The benefit is lower provider-get latency on the hot path while keeping resume safety, teardown safety, and observability intact ## Linked Issues or Issue Description This is a Daytona performance fix, not a standalone public GitHub issue. ### Problem / Motivation - Repeated `client.get(sandboxId)` calls on the sandbox hot path re-fetch a handle that is already started and trusted for the current lease. - The extra provider round-trip is pure overhead on repeated exec, sync, resume, and interactive-cancel flows. - Cache freshness also has to be tied to successful reuse, or a failed command can make a stale sandbox look freshly used. ### Proposed Solution - Cache the started `Sandbox` handle in process memory, keyed by a non-secret composite lease scope. - Enforce strict identity checks and eviction on release, destroy, interactive cancel, and resume-sentinel mismatch. - Block teardown cleanup until active lease operations finish so delete/stop cannot race in-flight execute or sync work. - Advance freshness only after successful execute, sync, or resume reuse, so failed operations do not mask an auto-stopped sandbox. - Preserve `getDurationMs` in exec metadata so provider-get latency remains observable. ### Alternatives Considered - Keep fetching the sandbox on every exec path. - Cache only by bare lease id. ### Roadmap Alignment - This change is part of the Daytona performance work and narrows per-call overhead without changing the public adapter contract. ## What Changed - Memoized the started Daytona `Sandbox` handle in a process-scoped cache keyed by a composite lease scope. - Added fail-closed identity checks so cache hits and single-flight populate paths reject mismatched sandbox ids. - Evicted cached handles on release, destroy, interactive cancel, and resume sentinel mismatch. - Blocked release, destroy, and interactive cancel teardown cleanup until active lease operations drain. - Advanced cache freshness only after successful execute, sync, and resume reuse. - Kept `getDurationMs` in exec metadata so provider-get latency remains observable. - Expanded the Daytona plugin tests to cover same-lease reuse, cross-scope isolation, eviction paths, rejected populate handling, concurrent single-flight behavior, cached-resume sentinel revalidation, teardown cancellation safety, and failed-execute freshness handling. ## Verification - `pnpm exec vitest run --config vitest.config.ts` in `packages/plugins/sandbox-providers/daytona` — 81/81 passing, including the teardown-cancel, snapshot-capture, syncIn-cancel, and failed-execute freshness regressions. - `git rev-parse origin/perf/daytona-sandbox-handle-cache` matched the authorized submit SHA `528158f998fa88bb0748300f156b38d86d6589cd` before the fixup commits. - `git log --oneline origin/master..origin/perf/daytona-sandbox-handle-cache` shows the expected focused Daytona changes. - GitHub duplicate/related PR search and ROADMAP review were completed before opening the PR. - Remote CI and Greptile completed successfully after this description was updated; the PR is now ready for board handoff. ## Risks - The cache is process-scoped, so correctness depends on the eviction paths staying complete. - A bug in the scope key or identity checks could leak reuse across the wrong lease boundaries, but the implementation fails closed on id mismatches. - Teardown now waits for active operations to drain, so any missed activity bookkeeping could delay cleanup instead of racing it. - Freshness updates now happen after success, which is safer, but it means any missed success-path call would trigger an extra refresh rather than silently masking staleness. ## Model Used OpenAI GPT-5 via Codex, tool-using coding agent; exact context window not surfaced in the workspace. ## 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>canary/v2026.728.0-canary.5 |
||
|
Devin FoleyandPaperclip
|
c274f10abc |
feat(server): computed owner instance-admin elevation for cloud-managed instances, behind platform floors (#10343)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Cloud-managed instances authenticate tenant users through a trusted-header path (`resolveCloudTenantActor`) that deliberately never grants `instance_admin`, so every tenant user is company-scoped > - On a dedicated (single-owner) managed instance that leaves the paying owner unable to administer their own instance: instance settings, the environments admin surface, and the custom sandbox image flow are all instance-admin gated (the environments UI can't even show the provider/image of the platform sandbox because the restricted read view blanks `config` entirely) > - Re-granting the old blanket `instance_user_roles` row would repeat the mistake the shared-pool hardening fixed: DB rows go stale, resurrect via restores, and elevate through every auth path > - This pull request elevates only the stack `owner`, computed per request at the trusted-header boundary behind a new managed-tier feature flag, and ships that elevation together with code floors on the platform-owned surfaces an instance admin must not control on a managed instance > - The benefit is that dedicated-stack owners can administer their own instance while platform credentials, execution policy, backups, and runtime code-install stay platform-owned, and self-hosted behavior is unchanged ## Linked Issues or Issue Description No public GitHub issue exists for this change; the underlying issue is described here following the feature-request template. ### Problem or motivation - On cloud-managed instances, tenant users resolved from trusted headers are always company-scoped. For dedicated instances with a single paying owner, the owner cannot reach any instance-admin surface of their own instance (instance settings, environments administration, custom image setup), and the restricted environment read view hides even structural fields like the sandbox provider and image. - The previous hardening intentionally removed blanket elevation (and purges stale `instance_user_roles` rows on every trusted-header authentication). That protection must not regress for shared multi-tenant pools. ### Proposed solution - Owner-only, computed, flag-gated elevation plus code floors on platform-owned surfaces, in one PR so the elevation can never ship without the floors. ### Alternatives considered - Re-inserting an `instance_user_roles` row for owners (the pre-hardening model): rejected — DB rows go stale, survive restores, and elevate through every auth path; #7525 removed exactly this. - Widening only the environments read view without any elevation: rejected — it fixes one screen but still leaves a dedicated-instance owner unable to administer instance settings or custom images. - Elevating additional stack roles (`member`/`admin`/`support`): rejected — only the owner has an ownership claim over the whole instance; other roles stay company-scoped. ### Roadmap alignment - Extends the shipped "Cloud deployments" roadmap work (multi-tenant isolation, company-scoped cloud tenants, managed-instance bootstrap) without overlapping planned core items, and leaves self-hosted behavior unchanged. ## What Changed - **New feature key** `enableOwnerInstanceAdmin` (`packages/shared`): boolean flag in `instanceExperimentalSettingsSchema`, catalog tier `managed`, `cloudDefault: true`, `selfHostedDefault: false`. Inert on self-hosted instances — the elevation path only exists behind the cloud tenant trust token. - **Computed elevation** (`server/src/middleware/auth.ts`): `resolveCloudTenantActor` now returns `isInstanceAdmin: true` only when the trusted-header stack role is `owner` **and** the flag is enabled. The flag is resolved through the instance-settings service so the managed-config overlay applies (the control plane can disable elevation fleet-wide without touching tenant databases; a DB row edit or restore cannot resurrect it). Resolution fails closed on settings read errors. The `instance_user_roles` never-insert and the per-request stale-row purge are byte-identical. `member`/`admin`/`support` stack roles stay company-scoped. - **Authorization guard split** (`server/src/services/authorization.ts`): the blanket-allow now trusts the actor's *computed* `isInstanceAdmin` flag (only the attested resolver can set it for `cloud_tenant` actors) while keeping the `instance_user_roles` DB lookup excluded for `cloud_tenant` — a stale or hand-inserted role row still elevates nothing. - **Floor F1 — platform environment credentials** (`server/src/routes/environments.ts`): on cloud-managed instances, platform-provisioned environment rows (`managedByPaperclip` marker, plus the legacy managed-Kubernetes marker) use a single floored view for every reader on all environment routes (list, get, create, update, delete responses): `envVars` are never echoed and credential-shaped `config` keys (reusing the managed-config `SECRET_LIKE_CONFIG_KEY_PATTERN`) are dropped — for **all** actors including instance admins — while structural config (provider, image, template, region, …) and the managed markers stay visible. This also fixes the environments UI for managed sandboxes, which previously lost the provider/image entirely in the restricted view. The floor also covers writes: `PATCH /environments/:id` and `DELETE /environments/:id` on a platform-provisioned row are rejected (403, `environment_platform_managed`) for every actor including instance admins, and the guard binds to the persisted row's markers so a patch cannot strip the managed marker to lift the floor. The one recovery path is a metadata-only PATCH that solely clears the marker keys (null/false), for rows stamped through the old unrestricted API before the markers became reserved — and it never applies to a row whose slot markers are live platform state: the single local row (`environments_local_driver_idx`), which `ensureLocalEnvironment` adopts and stamps on cloud-managed instances from every caller (company creation, the heartbeat, run orchestration), and the single marked sandbox row (`environments_managed_sandbox_idx`) while a managed-sandbox bootstrap path is configured (managed-config `environments` section or `PAPERCLIP_EXECUTION_MODE=kubernetes`) and the provisioner therefore adopts and refreshes it on every boot. Clearing a live slot row's markers would let the next write reclassify it as tenant-managed and bypass the floor; conversely, when no sandbox provisioning path is configured the platform holds no claim on any sandbox row, so a platform marker there is stale by definition and the recovery patch applies. Every marker outside a live slot is clearable, so no legacy row is ever locked permanently. Custom-image setup and probes on the platform sandbox stay available to instance admins — those are the owner-facing flows this elevation exists for. The marker keys themselves are reserved: client create/update payloads that set `managedByPaperclip` or `managedKubernetesSandbox` are rejected (422, `environment_platform_marker_reserved`) on cloud-managed instances, so a tenant row can never be stamped platform-provisioned through the API and self-locked behind the write floor (the provisioner writes markers at the service layer, not through these routes). Tenant-created environments are otherwise unaffected. - **Floor F2 — executionMode** (`server/src/routes/instance-settings.ts`): on cloud-managed instances, `PATCH /instance/settings/general` rejects writes that would change `executionMode` (403, `execution_mode_platform_managed`). Same-value echoes pass so settings forms that submit the full general-settings object keep working. The boot-time execution-policy bootstrap path is untouched (it calls the service directly). - **Floor F3 — manual database backups** (`server/src/routes/instance-database-backups.ts`): floored off on cloud-managed instances (403, `database_backups_platform_managed`); backups are platform-owned there, and the result would also echo a server-side filesystem path. - **Floor F4 — adapter code install** (`server/src/routes/adapters.ts`): `POST /adapters/install` and `POST /adapters/:type/reinstall` are floored off on cloud-managed instances (403, `adapter_install_platform_managed`). Adapter packages execute in the server process, so a runtime install would let an instance admin read the platform trust anchors out of the process environment. This mirrors the existing bundled-only plugin install floor; adapter code on managed instances comes bundled with the platform image. ## Instance-admin surface audit Before widening who can hold `isInstanceAdmin`, every instance-admin-gated surface in `server/src` was enumerated and reviewed for whether its response or side effects could echo process environment values or platform credentials (tenant trust token, JWT signing keys, database connection strings, provider API keys): 29 distinct gate definitions covering ~90+ call sites, in four groups — sole instance-admin gates (12), instance-admin-or-company-permission gates (10), response-shaping/scope-widening sites (6), and the central `allow_instance_admin` short-circuit in the authorization service (58 `decide()` call sites). Findings and dispositions: - **Environment read/write responses** exposed platform sandbox `envVars`/credential-shaped config to instance admins → closed by floor F1. - **Manual backup trigger** echoed a server filesystem path and triggers a platform-owned operation → closed by floor F3. - **Adapter install/reinstall** loads externally fetched code into the server process (indirect, complete env exposure) → closed by floor F4. The sibling plugin-install path already had a bundled-only floor on managed instances and needed no change. - **Token-minting surfaces** (gateway tokens, custom-image terminal/connection tokens) mint credentials scoped to the instance's own resources, not platform trust anchors → acceptable for an owner-admin of a dedicated instance; unchanged. - All remaining gated surfaces return ordinary instance-scoped business data; none echo `process.env` or platform secrets directly. OAuth client secrets are referenced by env-var *name* only; SSH private keys are stored as secret refs before persistence and are not echoed. Operational note for managed platforms: this model assumes the process environment of a managed instance holds only that instance's own credentials. Platform operators should keep provider credentials per-instance (never fleet-shared) since an instance admin ultimately controls in-process code on their own instance. ## Verification - `pnpm vitest run server/src/middleware/cloud-tenant-actor.test.ts` — resolver matrix: owner × flag on/off, flag via managed overlay (on-over-DB-off and off-over-DB-on), member/admin/support × flag on, no-token self-hosted, fail-closed settings read, purge still runs and no role row is ever inserted (14 tests). - `pnpm vitest run server/src/__tests__/authorization-service.test.ts` — computed flag elevates a `cloud_tenant` actor; a stale `instance_user_roles` row still never does; `session` actors unchanged (full suite, embedded Postgres). - `pnpm vitest run server/src/__tests__/environment-routes.test.ts` — F1: no secret echo to admins on get/list, structural config visible to restricted readers, platform-row PATCH/DELETE rejected for admins (including a marker-stripping patch), marker-clear recovery allowed for stale legacy rows and for a marked sandbox row when no provisioning path is configured, but refused on the managed local row and on the sandbox slot row under a managed-config `environments` entry or the forced kubernetes execution mode, client marker-stamping creates/patches rejected, tenant rows still readable and writable, self-hosted read+write regression (60 tests). - `pnpm vitest run server/src/__tests__/environment-service.test.ts` — `ensureLocalEnvironment` adopts a pre-existing local row on cloud-managed instances (marker stamped, other metadata preserved, idempotent — no rewrite on re-ensure) and leaves self-hosted rows untouched (22 tests, embedded Postgres). - `pnpm vitest run server/src/__tests__/instance-settings-routes.test.ts server/src/__tests__/instance-database-backups-routes.test.ts` — F2 change-vs-echo matrix incl. self-hosted regression; F3 floor for both admin shapes (32 tests). - `pnpm vitest run server/src/__tests__/adapter-routes-authz.test.ts` — F4 floor; self-hosted install/reinstall behavior unchanged (existing cases). - `pnpm vitest run server/src/__tests__/first-admin-claim.test.ts server/src/__tests__/bootstrap-claim-routes.test.ts server/src/__tests__/managed-config.test.ts server/src/__tests__/health.test.ts server/src/__tests__/instance-settings-managed-overlay.test.ts server/src/services/managed-environments.test.ts server/src/services/execution-policy-bootstrap.test.ts` — first-admin bootstrap gate and managed-config behavior unchanged (91 tests). - `pnpm vitest run packages/shared/src/feature-catalog.test.ts` — catalog/schema sync tests cover the new key (selfHostedDefault must equal the schema default). - `pnpm run typecheck` — all 31 workspace projects clean. ## Risks - Self-hosted behavior is unchanged: every floor binds to `isCloudManagedInstance()` (tenant trust token present), the new flag defaults off with no elevation path, and regression tests pin the self-hosted branches. - The elevation is fail-closed and stateless: turning the flag off (managed overlay or DB) de-elevates on the next request; there is no role row to clean up and restores cannot resurrect elevation. - On a cloud-managed instance a pre-existing unmarked local row is adopted (stamped `managedByPaperclip`) by the next ensure and becomes platform-owned — the intended managed-product semantic: the platform owns the single local slot. Self-hosted instances are untouched. - F1 widens restricted readers' view of platform-provisioned rows from fully blanked `config`/`metadata` to structural-only `config` plus markers. Platform-delivered config is guaranteed secret-free by the managed-config contract (secret-shaped keys fail startup), and the floor re-drops secret-shaped keys defensively. - One extra instance-settings read per trusted-header request for owner-role actors (the resolver already performs several queries per request). ## Model Used Claude Fable 5 (Anthropic) — model id `claude-fable-5`, extended thinking enabled, agentic tool use via Claude Code; read-only explore subagents on the same model were used for the surface audit sweep. ## 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 - [ ] 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>canary/v2026.728.0-canary.4 |
||
|
DottaandPaperclip
|
c3bd0c5d50 |
feat(skills): add beta releases for the core Paperclip skill (#10228)
## Thinking Path > - Paperclip is the open source control plane people use to organize and operate AI-agent companies. > - Agent behavior depends partly on the bundled Paperclip core skill synchronized into each runtime. > - The existing database and runtime plumbing already supports immutable skill-version snapshots and per-agent version selections, but no product workflow exposed that capability. > - Replacing the live bundled skill globally would make champion adoption risky and difficult to compare across agents. > - This pull request adds an experimental, instance-level beta-skills gate plus a repository release registry, immutable seeded releases, enforcement, and a per-agent release picker. > - The benefit is controlled per-agent evaluation of frozen core-skill releases while the default-off path remains behaviorally unchanged. ## Linked Issues or Issue Description ### Subsystem affected Cross-cutting: `server/`, `ui/`, `packages/db`, and `packages/shared`. ### Problem or motivation Paperclip needs a safe way to evaluate improved versions of its core operating skill without globally replacing the live default. Today the version-snapshot and per-agent pin plumbing exists, but operators cannot use it. A global replacement would make regressions difficult to contain and would prevent controlled comparisons across agents. ### Proposed solution Add a default-off instance experiment that exposes immutable, named core-skill releases. When enabled, operators can pin each agent to a seeded release; when disabled, every agent resolves the live default while saved pins remain intact. Validate pinned writes at the API boundary, gate reads at runtime, and expose the selection in the agent Skills tab. ### Alternatives considered - **Replace the bundled core skill globally:** rejected because it changes every agent at once and provides no rollback/isolation boundary. - **Ship releases as separate skills:** rejected because releases are versions of one core capability, not independently enabled skills. - **Store release snapshots only outside the repository:** rejected because repository provenance and hashes make builds reproducible and reviewable. ### Roadmap alignment This extends the Skills Manager / Skill Studio direction in `ROADMAP.md` by making core-skill versions operable per agent. It does not duplicate another open implementation PR; GitHub searches found no related `enableBetaSkills` change. ### Additional context The feature remains experimental and default off. The V7 champion was selected through a multi-model evaluation process, and the frozen release contents are verified by SHA-256 below. ## What Changed - Added the default-off instance-level `enableBetaSkills` experimental flag. - Added `skills-releases/paperclip/` with the ordered release registry and frozen `v0` plus `v7-roster` snapshots. - Added release metadata to `company_skill_versions` and idempotent release seeding. The migration was planned as `0191`, then renumbered to `0192` because current `master` claimed `0191` before final rebase. - Added read-time gating and write-time validation so disabled instances always resolve the live default and reject pinned-version writes. - Added the per-agent Release picker in the agent Skills tab, including responsive layout and beta-pin state. - Kept `EDITS.md` out of the release registry and PR diff. ### V7 Adoption Evidence - Paid roster: 6 models, 94-case suite. - Result: 553/564 pass-within-2, mean 92.17/94, versus the P2 baseline of 544/564. - Reference model improved 84→91; maximin improved 84→90. - Final report: https://pages.paperclip.ing/skills/optimization/paperclip/pap-14624-p3-final-20260721/ ### Provenance - `v7-roster` is the Phase 1 champion plus additions-only edits E107–E112. Per-edit rationale remains in the evals repository at `source/v7-roster/EDITS.md` and is deliberately excluded from this PR. - `v0` is the `skills/paperclip` tree from commit `ea66ea81`. - Champion selection was accepted on July 21, 2026 via board card `9c304fc2` (PAP-14624 G3). - This delivery mechanism was accepted on July 24, 2026 via plan revision `2367abd2` (PAP-14858). ### QA Evidence - P4 QA matrix comment `b7f40522-4e9b-4a3a-9821-28e86fe1a987`: all 6 acceptance criteria passed. - Automated QA matrix: 166 tests passed with 0 failures, including real filesystem materialization and full SHA-256 assertions. - UI QA exercised the real agent Skills tab at desktop and mobile widths with the experimental flag both on and off. ## Verification - `pnpm check:token-gates` - Focused beta-release matrix: 169 tests passed across shared validators, server services/routes/heartbeat behavior, instance settings UI, and release picker UI. - `pnpm -r typecheck` - `pnpm build` - `pnpm test:run`: server and UI partitions passed; one CLI doctor test inherited temporary AWS credentials from the agent heartbeat and expected no static credentials. The isolated rerun with `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN` unset passed 8/8. - V7 SHA-256: - `SKILL.md`: `53ab290489684cbf116fdd1406a95f6b6f53c9c36358b1bf8bfeae481e253575` - `references/cases.md`: `3b821f59064a7761091020a14819a8d787131f24029748563d6c0e1be7e6eaec` - `references/workflows.md`: `69747bd6e05f7e3673d1e67b07ff295df1869c05e1fd029804d5fa9177db92cd` - Confirmed 49 changed files, no `pnpm-lock.yaml`, no workflow changes, and no `EDITS.md`. ## Risks - **Migration:** low-to-moderate risk. Three nullable columns and one partial unique index are added idempotently; existing rows remain valid. - **Behavior:** low risk while the flag is off because read-time resolution forces the live default and saved pins are preserved but inactive. - **Frozen content:** release snapshots intentionally diverge from future live skill edits; provenance and hashes make that divergence explicit and reproducible. - **UI:** low risk. The picker only renders for the bundled core skill when the experimental flag is enabled and seeded releases exist. > This extends the existing Skills Manager / Skill Studio direction described in `ROADMAP.md`; it does not duplicate another open implementation PR. The GitHub PR search found no related `enableBetaSkills` change. ## Model Used - OpenAI Codex using `gpt-5.5` with reasoning and terminal/code-execution tools; context-window size is not exposed by this runtime. Earlier implementation commits also record Claude Opus 4.8 assistance where applicable. ## 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 - [ ] I have not referenced internal/instance-local Paperclip issues or links (required governance identifiers are included above; no internal URL is included) - [ ] My branch name describes the change and contains no internal Paperclip ticket id (the approved delivery plan mandated this shared branch name) - [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>canary/v2026.728.0-canary.3 |
||
|
Nicky LeachandPaperclip
|
030dd9d15c |
feat(adapter-utils): provider-delegable syncIn seam with ordered post-upload commands (#10340)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The adapter/runtime layer has to move files into sandboxes safely and efficiently > - The current sync-in path needs a provider-delegable seam so providers can use their native upload transport when available > - The upload contract also needs ordered post-upload commands so extracted content can be finalized fail-fast after transfer > - The fallback path still has to preserve current behavior when the provider does not expose native sync verbs > - This pull request adds the contract and runtime seam for provider-delegable sync-in, plus the single-stream collapse flag > - The benefit is fewer round trips, a cleaner provider-owned upload path, and a compatible fallback for existing runners ## Linked Issues or Issue Description No public GitHub issue exists for this change. The underlying feature request is described below in the repository's feature-request format. ### Problem or motivation Paperclip needs a sync-in path that lets each provider choose the best available upload transport instead of forcing the harness to orchestrate uploads the same way every time. The runtime also needs a way to describe ordered post-upload commands so providers can finalize extracted content fail-fast after transfer. ### Proposed solution Extend the sync contract with ordered post-upload commands, forward that contract through the plugin and environment runtime layers, and make client syncIn always available. When a provider advertises native sync verbs, the client should delegate to that transport; otherwise it should fall back to the existing tarball/write/extract behavior and then run the post-upload commands in order. ### Alternatives considered Keeping upload orchestration entirely host-side would avoid a contract change, but it would block provider-specific transport optimizations and keep the harness responsible for a path the provider can do more efficiently. A separate post-upload API would add another surface without improving the existing sync flow. ### Roadmap alignment This work aligns with the broader runtime and adapter roadmap because it improves provider integration without changing the external product model. It is an additive contract change that preserves backward compatibility for providers that do not expose native sync verbs. ### Additional context The fallback path still needs to preserve existing observable behavior, including command ordering, cwd confinement, and fail-fast execution. The single-stream progress flag is part of the same transport improvement so smaller writes can collapse to a single round trip when the runner supports it. ## What Changed - Added ordered `postUploadCommands` support to the sync operation contract and SDK mirror. - Plumbed the sync-in contract through the plugin and environment runtime layers. - Implemented a runtime client `syncIn` path that delegates to native provider transport when available, otherwise uses the generic tarball/write/extract fallback. - Preserved fail-fast execution of ordered post-upload commands in the fallback path. - Flipped the sandbox runner's single-stream stdin progress flag to collapse small `writeFile` operations to a single round trip. - Added and updated tests for contract forwarding, fallback behavior, cwd rejection, fail-fast behavior, and single-stream collapse. ## Verification - `pnpm --filter @paperclipai/plugin-sdk exec vitest run protocol.postupload.test.ts` - `pnpm --filter @paperclipai/plugin-sdk exec vitest run environment-sync-negotiation.test.ts` - `pnpm --filter @paperclipai/adapter-utils exec vitest run command-managed-runtime.test.ts` - `pnpm --filter @paperclipai/server exec vitest run environment-execution-target.test.ts` - Local typecheck and targeted suite runs reported in the handoff passed before PR creation. ## Risks - The new fallback path could diverge from the previous inline upload behavior if the tarball/extract contract changes. - Provider-native sync handling may expose provider-specific edge cases if a runner advertises sync verbs but does not fully honor the contract. - The single-stream flag changes transport behavior for small uploads, so regressions would likely show up as round-trip or upload failures. ## Model Used OpenAI Codex (GPT-5, tool-using coding agent). ## 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 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>canary/v2026.728.0-canary.2 |
||
|
DottaandPaperclip
|
c111ee4cb3 |
feat(server): add per-user document stars (#9952)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies and their work. > - Artifacts and documents are first-class outputs, but users need a personal way to keep important documents easy to find. > - Existing resource memberships already model per-user starred projects and agents with company scoping and activity logging. > - Documents lacked the equivalent membership model, route, and artifact filtering behavior. > - The shared membership contract also needs to remain safe for existing UI project/agent mutation helpers when documents become a recognized resource type. > - This pull request extends the existing resource-membership system with per-user document stars and a starred artifacts view. > - The benefit is a company-scoped, idempotent server foundation for a dedicated starred-documents experience without weakening authorization or artifact filtering semantics. ## Linked Issues or Issue Description ### Problem / Motivation Board users cannot star individual documents, and the company artifacts API cannot return only the current user's starred documents. ### Proposed Solution Add company/user-scoped document memberships, a board-only document star route, document membership data in the shared contract, and a `starred=true` artifacts filter. ### Alternatives Considered A document column was rejected because stars are per-user; a separate star API was rejected because projects and agents already use resource memberships. ### Roadmap Alignment This extends the existing Artifacts & Work Products roadmap area and does not duplicate another open pull request found in the repository search. ## What Changed - Added the `document_memberships` schema and migration with company/user/document uniqueness and starred ordering. - Extended shared resource-membership and artifact-query contracts for documents and `starred=true`. - Added company-scoped document star/unstar service and board-only route behavior with activity logging. - Added starred document artifact filtering, including user-authored documents, document kinds, cursor ordering, and incompatible-kind handling. - Preserved idempotency under concurrent star requests and synchronized UI membership defaults/helpers with the expanded contract. - Added focused shared, route, service, and UI regression coverage. ## Verification - `pnpm exec vitest run packages/shared/src/resource-memberships.test.ts server/src/__tests__/company-artifacts-service.test.ts server/src/__tests__/resource-memberships-routes.test.ts` - `pnpm exec vitest run ui/src/components/SidebarAgents.test.tsx ui/src/components/SidebarProjects.test.tsx ui/src/components/SidebarStarredProjects.test.tsx` - `pnpm --filter @paperclipai/db check:migrations` - `pnpm -r typecheck` - `pnpm test:run` - `pnpm build` ## Risks - The migration adds a new membership table and non-concurrent indexes; migration safety gates pass with the repository's established policy. - The starred artifacts query intentionally returns only documents and relaxes the normal agent-authored/system-kind predicates for documents the current user explicitly starred. - Document membership mutations remain board-user-only; agent callers receive no document-star capability. > 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 CLI; runtime model ID and context-window size were not exposed to this session. Reasoning, repository tool use, code execution, and test execution were 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 - [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>canary/v2026.728.0-canary.1 |
||
|
DottaandPaperclip
|
3b0156238a |
docs(connections): cross-reference the identity model (identity vs. connections) (#9953)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Integrations are governed through the Apps v2 "connections" substrate documented in `doc/connections/` > - Contributors adding connectors had no written boundary between *signing a user in* (identity) and *connecting an external resource* (a connection), so app-store work could drift into merging the two > - Unwritten, that boundary risks a design where a sign-in provider's token gets reused as a resource token, or the identity service grows a connections hub — exactly the failure the separation exists to prevent > - This pull request adds an "Identity vs. connections" section to the public connections docs that names the three planes, states the standing rule verbatim, and aligns naming across surfaces > - The benefit is that connector implementers inherit the identity/connection boundary from accessible repository documentation instead of re-deriving it ## Linked Issues or Issue Description Docs-only change. No public GitHub issue. **Problem:** The `doc/connections/` docs describe how to add a connector (the First-30 matrix and connector playbook) but never state where identity ends and connections begin. Without an accessible statement of that boundary, connector work can accidentally blur sign-in tokens and resource tokens. **Change:** Adds a public reference section fixing the boundary and makes it self-contained for contributors without access to private identity-service implementation documentation. ## What Changed - `doc/connections/README.md`: adds an **Identity vs. connections** section with the P1/P2/P3 model, D7 standing rule, rationale, naming alignment, and canonical-doc cross-reference. - `doc/connections/FIRST-30-MATRIX.md`: notes that every listed provider is a plane-P2 connection and links the new section. - `doc/connections/CONNECTOR-PLAYBOOK.md`: points connector authors to the boundary and standing rule before implementation. - Removes inaccessible private-repository documentation links so every reference in the new public guidance is usable by contributors. ## Verification - `git diff --check origin/master...HEAD` - Verified Markdown table column consistency across the three changed files. - Verified no private `paperclip-id` URLs or new internal Paperclip issue references remain in the diff. - Current-head CI is fully green, including typecheck, build, server/workspace tests, serialized suites, canary, and both e2e shards. - Greptile reviewed commit `d964abab50b39a79fef394c0b1855dd1f2e4b92b` at 5/5 with no unresolved findings; its connections-doc validation returned `RESULT: PASS`. ## Risks Low risk — documentation only. No code, schema, migration, or runtime behavior changes. > 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 - Anthropic Claude Opus 4.8 (`claude-opus-4-8`), 1M context, extended thinking with tool use, authored the initial documentation change. - OpenAI Codex CLI (runtime model identifier not exposed to this session), agentic reasoning with shell and GitHub tooling, performed PR preparation, rebase, review-loop diagnosis, and the public-link correction. ## 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> |
||
|
DottaandPaperclip
|
1426494ab8 |
fix(agents): disable cheap model profiles by default (#10019)
## Thinking Path
> - Paperclip is the control plane people use to create and govern
AI-agent companies
> - Agent creation persists runtime configuration that controls which
model profiles future runs may select
> - Adapters can expose a `cheap` profile, and existing creation paths
implicitly left that profile available when operators made no choice
> - That made a newly created agent eligible for a lower-cost model
without an explicit operator opt-in
> - The UI also dropped an explicit opt-in when the operator selected
the adapter's default cheap model rather than a custom model ID
> - Codex additionally hardcoded `gpt-5.3-codex-spark` into its cheap
profile and static fallback model list, making Paperclip choose an
auth-dependent model rather than requiring an operator choice
> - This pull request makes new-agent creation disable an available
cheap profile by default while preserving explicit opt-in from the UI or
API
> - The Codex cheap profile now remains available for explicit
configuration but supplies no model default, so an unconfigured cheap
request stays on the primary model
> - The benefit is predictable model quality for new agents and an
intentional, auditable choice before lower-cost routing is enabled
## Linked Issues or Issue Description
**Problem**
New agents created with an adapter that exposes a `cheap` model profile
can inherit that profile without the operator explicitly enabling it. In
the UI, enabling the adapter-default cheap model is also omitted because
runtime configuration is only written when a custom model ID is present.
**Expected behavior**
- New agents default an available `cheap` model profile to `{ enabled:
false }` when the caller does not specify it.
- Explicit API configuration remains authoritative.
- UI opt-in persists even when the adapter default model is used.
- Codex does not advertise or automatically select
`gpt-5.3-codex-spark`; operators must explicitly configure any
lower-cost Codex model.
**Related public work**
- Refs #4881, which introduced cheap model profiles for local adapters.
- Supersedes the default-selection portions of #8032 and #10004 by
removing the Codex model default instead of replacing it with another
hardcoded model.
## What Changed
- Detect whether the selected adapter exposes a `cheap` model profile
during agent creation and hiring.
- Persist `runtimeConfig.modelProfiles.cheap.enabled = false` only when
the caller did not explicitly configure the profile.
- Preserve UI cheap-profile opt-in when using the adapter's default
model by writing an empty adapter config.
- Remove `gpt-5.3-codex-spark` from the Codex static model list.
- Keep the Codex `cheap` profile explicitly configurable while giving it
an empty adapter config, so Paperclip never chooses a cheap Codex model
automatically.
- Verify that a Codex cheap request without an explicit model leaves the
primary model unchanged.
- Extend server route and UI runtime-config tests for default-disable
and explicit-opt-in behavior.
## Verification
- `env -u PAPERCLIP_IN_WORKTREE -u PAPERCLIP_WORKTREE_NAME -u
PAPERCLIP_CONFIG -u PAPERCLIP_HOME -u PAPERCLIP_INSTANCE_ID -u
PAPERCLIP_CONTEXT pnpm exec vitest run
packages/adapters/codex-local/src/index.test.ts
packages/adapters/codex-local/src/server/codex-args.test.ts
server/src/__tests__/adapter-models.test.ts
server/src/__tests__/adapter-registry.test.ts
server/src/__tests__/heartbeat-model-profile.test.ts
server/src/__tests__/agent-permissions-routes.test.ts
ui/src/lib/new-agent-runtime-config.test.ts`
- Result: 7 test files passed, 105 tests passed.
- GitHub `Typecheck + Release Registry` check passed on the final head.
- `git diff --check public-gh/master...HEAD`
## Risks
- Low behavioral risk: only newly created or hired agents are
normalized; existing agents are unchanged.
- Explicit `cheap` profile settings remain untouched, including explicit
opt-in.
- Codex users who explicitly opt into the cheap lane must choose a
model; requests without a configured override intentionally continue on
the primary model.
- Adapter profile discovery is now awaited during creation, adding a
small amount of adapter metadata lookup work.
- The source branch name is automation-provided and retained as required
by the task, so it does not satisfy the preferred public branch naming
convention.
> 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 `gpt-5.4` via Codex CLI, with reasoning, repository editing,
terminal execution, and GitHub/Paperclip tool access. The runtime did
not expose a context-window size.
## 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)
- [ ] 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>
|
||
|
DottaandPaperclip
|
71a6535792 |
docs(execution-semantics): define routable blocking and watchdog restoration (#10094)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies. > - Execution semantics define when work may stop, how child work reports upward, and how watchdog recovery proves liveness was restored. > - The existing docs did not require a routable waiting path before entering `blocked`, leaving permission-denial and review workflows vulnerable to dead ends. > - Child-to-parent reporting and low-trust review delegation also needed explicit channels and ownership boundaries. > - Watchdog recovery needed bounded restoration verification rather than treating a recovery write as proof of restored progress. > - The security-sensitive defaults were reviewed and approved before publication. > - This pull request documents those contracts and synchronizes the bundled Paperclip skills that operationalize them. > - The benefit is clearer stop conditions, safer reporting defaults, and bounded watchdog recovery without sacrificing liveness. ## Linked Issues or Issue Description - No public GitHub issue exists for this execution-semantics documentation phase, so the problem and solution are described here in full. - Problem: `blocked` could be entered without a routable owner/action path, review findings could be reported on the wrong issue or treated as blockers, and watchdog recovery lacked bounded verification of restored liveness. ## What Changed - Require a routable waiting path for `blocked` and clarify that permission denial alone is not a blocker. - Define canonical child-to-parent completion/report channels, review-delegation ownership, and the sanctioned courier pattern. - Specify atomic watchdog recovery batches, fingerprint validation, bounded restoration attempts, and human escalation. - Document the low-trust preset default for report comments and align both bundled Paperclip skills. ## Scope and Sequencing - This is the contract-first P1 documentation PR. Runtime enforcement is intentionally excluded and follows in the separately owned implementation phases; these docs define the acceptance contract those phases must satisfy. - The five-file patch is approved and frozen for this PR, so review findings about absent runtime support are tracked as implementation-phase requirements rather than edits to this docs-only change. ## Verification - `git diff --check origin/master...HEAD` - Confirmed the PR diff is exactly 5 approved docs/skill files with 91 insertions and 1 deletion. - Confirmed the patch preserves the approved execution-semantics contract after replay on latest `origin/master`. ## Risks - Low implementation risk: documentation and skill guidance only; no runtime code, schema, migration, dependency, lockfile, or workflow changes. - Semantic risk is limited to readers or agents applying the clarified contracts; the security-sensitive R1a default was approved before publication. > 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 (exact underlying model ID and context-window size are not exposed by this runtime), with reasoning, terminal tool use, Git/GitHub operations, 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 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 private URLs or internal issue identifiers - [x] My branch name describes the change and contains no internal Paperclip ticket id - [x] I have run the applicable docs-only checks locally and they pass - [x] Tests are not applicable because this is a docs/skill-guidance-only change - [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> |
||
|
DottaandPaperclip
|
8339bcc7e7 |
fix(ui): keep decision training under decisions (#10181)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Operators review decisions and turn useful outcomes into training examples > - The training library belongs to the Decisions surface, but its routes and entry point appeared as a separate top-level destination > - That mismatch made the training icon feel disconnected and left internal links pointing at legacy `/training` URLs > - This pull request nests the training library and inspector under `/decisions/training`, keeps legacy URLs working through redirects, and uses one route helper everywhere > - The benefit is a clearer Decisions workflow without breaking existing bookmarks or links ## Linked Issues or Issue Description Refs: #9718 Refs: #9779 **Problem:** The Decisions page exposed training as a labeled header action while the training library lived at the unrelated top-level `/training` route. Links across the UI duplicated that legacy path. **Expected behavior:** Training should be an icon action alongside the other Decisions controls, and training library/record URLs should live under `/decisions/training` while old URLs continue to redirect. **Steps to reproduce:** 1. Open the Decisions page. 2. Observe the separate labeled Training button in the page heading. 3. Open a training record and note the top-level `/training/...` URL. **Version/commit:** Current `master` before this PR. **Deployment mode:** All UI deployment modes. ## What Changed - Move the training library and inspector routes under `/decisions/training`. - Redirect legacy `/training` and `/training/:id` URLs to the new locations. - Add `decisionTrainingHref()` and use it for training links and navigation. - Place the Training icon action with the Decisions filter and sort controls. - Add focused tests for library and record URL generation. ## Verification - `pnpm exec vitest run ui/src/lib/decisionTraining.test.ts` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm --filter @paperclipai/ui build` - `pnpm check:token-gates` ## Risks - Low risk: the change is limited to client-side routes and navigation. - Existing `/training` bookmarks remain supported through replacement redirects. - No API, database, migration, dependency, or workflow changes. > 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 using GPT-5.4 with reasoning, repository tool use, shell execution, and code/test verification. ## 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> |
||
|
|
0cf64d36a5 |
feat(secrets): write through external values and deep-link details (#10196)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies. > - Its secrets subsystem can resolve external references such as AWS Secrets Manager values without copying those values into Paperclip custody. > - Operators also need to rotate a referenced secret's value while preserving the same provider reference for consumers inside and outside Paperclip. > - Previously, external-reference rotation could only retarget metadata, and secret detail sheets were driven by local component state rather than shareable navigation state. > - This pull request adds an optional provider write capability, implements AWS Secrets Manager write-through rotation, and exposes capability-aware rotate modes in the UI. > - It also makes secret and each-user definition detail sheets URL-driven and adds a copy-link action. > - The benefit is that operators can update the canonical external value safely while keeping AWS rotation tracking intact, and they can share or navigate directly to secret details. ## Linked Issues or Issue Description ### Subsystem affected Cross-cutting (`server/`, `ui/`, and `packages/shared`). ### Problem or motivation External-reference secrets can follow a provider-managed value, but Paperclip could not write a replacement value back to providers that support it. Operators had to leave Paperclip, update the value separately, and then return without an auditable Paperclip rotation record. Secret detail sheets also could not be shared or restored through browser history because their selection lived only in component state. ### Proposed solution Add an optional `updateExternalSecretValue` provider capability and surface it as `supportsExternalValueWrites`. Implement AWS writes with `PutSecretValue` while leaving the resolution `versionId` unset so future reads continue following `AWSCURRENT`. Add write-value and retarget modes to the rotate dialog for capable providers. Drive secret detail selection from `?secret=` / `?definition=` query parameters and provide a copy-link action. ### Alternatives considered Converting an external reference into a Paperclip-managed secret would break consumers that depend on the existing provider reference. Pinning reads to the newly written AWS version would prevent later out-of-band rotations from flowing through. Keeping sheet selection only in React state would not support browser Back or shareable links. ### Roadmap alignment This extends the completed “Secrets Manager with per-agent access” roadmap capability; it does not duplicate a separate planned roadmap item. Public GitHub searches found no duplicate or closely related issue or PR. ### Additional context The PR includes focused provider, service, and UI render coverage. Cutter also generated previews for the deep-linked detail sheet and capability-aware rotate modes. ## What Changed - Added optional external-value write support to the secret provider contract and provider descriptors. - Implemented AWS Secrets Manager write-through with `PutSecretValue`, audit material, and compensation when persistence fails after the provider write. - Allowed `secretService.rotate()` value updates for external references while rejecting ambiguous value-plus-retarget combinations and unsupported providers. - Added capability-aware “Write new value” and “Change reference” rotate modes with updated custody and action copy. - Made secret and each-user definition detail sheets source their selection from URL query parameters, compose with folder paths, close through browser history, and expose a copy-link action. - Added provider, service, and UI render coverage for write-through, rollback, capability messaging, dialog modes, and deep links. ## Verification - `pnpm vitest run server/src/__tests__/aws-secrets-manager-provider.test.ts` — 18 passed. - `pnpm vitest run server/src/__tests__/secrets-service.test.ts` — 75 passed. - `pnpm vitest run ui/src/pages/Secrets.render.test.tsx` — 31 passed. - `pnpm --filter @paperclipai/shared typecheck` — passed. - `pnpm --filter @paperclipai/server typecheck` — passed. - `pnpm --filter @paperclipai/ui typecheck` — passed. - `pnpm check:token-gates` — passed with all gates clean. ## Risks - External value writes affect the canonical provider secret and therefore all consumers of that AWS secret; the UI explicitly labels this custody behavior. - A provider write can succeed before Paperclip persistence fails. The service records the written version and AWS support includes compensation coverage to restore the prior value where possible; unrecoverable failures return explicit audit-safe error details. - URL-driven sheet state changes navigation behavior; render tests cover deep links, Back/close behavior, and composition with folder query state. - No database migration or breaking API requirement is introduced; providers without the optional capability retain reference-only behavior. > 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 using exact model ID `gpt-5.6-sol`, high reasoning mode, Codex CLI `0.142.5`, with repository, shell, Git, GitHub CLI, and code-execution tools. The runtime did not expose a context-window size. - Earlier implementation commits were assisted by Anthropic `Claude Fable 5` as recorded in their commit trailers; the exact backend model ID and context-window size were not preserved in the workspace metadata. ## 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 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, or confirmed no documentation change is required - [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: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|
DottaandPaperclip
|
ab2bdfeebb |
feat(routines): activity-gated advanced run policy (editor + run rows) (#10225)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Scheduled routines provide recurring control-plane work without manual intervention. > - The activity gate (`activity_gate_policy` / `activity_gate_scope`) lets a scheduled routine skip a tick when nothing has happened since its last run, so watcher-style routines stay asleep while the system is settled instead of burning tokens every tick. > - The scheduler, database columns, and the create/update API for those fields already landed (see #9438), but there was no way for an operator to actually set the policy from the routine editor, and the runs list rendered gated skips as bare "skipped" rows with no "why". > - This pull request adds the editor control and the run-row labels: the Delivery section gets an "Advanced run policy" picker plus a scope selector, and skipped runs explain why they were skipped. > - The benefit is that the activity gate becomes discoverable and usable end-to-end from the UI, closing the loop on the feature the API already supports. ## Linked Issues or Issue Description - Refs #8534 — activity gate for scheduled routines. - Builds on #9438 (merged) which exposed the activity-gate create/update API and the `Routine` response fields this UI reads and writes. This PR is the editor/UI companion to that API work. ## What Changed - **Routine editor — Advanced run policy control** (`ui/src/components/routine-sections/editable-sections.tsx`): the Delivery section gains a `RadioCardGroup` to choose between *Run on every scheduled tick* (default) and *Skip when there's been no activity since the last run*. When gating is enabled, a second scope picker (*Company-wide* / *This project*) appears. The control is **disabled with an explanatory hint** — rather than hidden — when the routine has no schedule trigger, since the gate only affects scheduled ticks (webhook/manual/API fires are themselves activity and always run). This keeps the capability discoverable. - **Edit-draft plumbing** (`ui/src/components/routine-sections/context.tsx`, `ui/src/pages/RoutineDetail.tsx`): `activityGatePolicy` / `activityGateScope` flow through the edit draft, the delivery section's dirty-field detection, the save payload, and revision restore, matching how `concurrencyPolicy` / `catchUpPolicy` are handled. - **Run-history skip reasons** (`ui/src/lib/routine-run-display.ts`): skipped run rows now render a human-readable "why" — `no_external_activity` → "Skipped — no activity since last run", plus labels for `paused` and `worktree_execution_cutoff` — instead of a bare status. - Storybook fixture updates for the new routine fields, plus focused run-display coverage for the skipped-run labels. ## Verification - `pnpm exec vitest run ui/src/lib/routine-run-display.test.ts` — 11 tests passing. - `pnpm --filter @paperclipai/ui typecheck` — clean. - `pnpm check:token-gates` — all token gates clean. - `pnpm --filter @paperclipai/ui build` — production build succeeds. - Current-head GitHub CI for `9f9af8ecccfadcdc4a3afab313aafad81cbd1112` — all checks pass (Storybook visual check skipped by workflow policy). ## Risks - **Low risk.** UI-only change; no schema/migration and no server changes (the API and columns already shipped in #9438). Fields are optional and default to the pre-feature behavior (`always` / `company`), so existing routines are unaffected. The scope picker only renders when gating is turned on, and the whole control is inert without a schedule trigger. ## Model Used - Claude Opus 4.8 (`claude-opus-4-8`, 1M context), extended thinking, with tool use (repo edit + shell verification). ## 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> |
||
|
DottaandPaperclip
|
f6ab82d490 |
feat(interactions): add interaction withdrawal and terminal-issue expiry (#10251)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents and boards coordinate through issue-thread interactions (request_confirmation, ask_user_questions, suggest_tasks, …) that wait as `pending` cards until someone resolves them > - Two lifecycle gaps existed: an interaction's creator could not take back a card it no longer stands behind, and interactions left `pending` on issues that reached a terminal status lingered forever as live-looking approval requests > - Stale pending cards mislead humans (they look actionable), distort attention/liveness signals, and in the worst case invite acting on a proposal whose issue is already closed or cancelled > - This pull request adds an explicit withdraw route for pending interactions and automatically expires pending interactions when their issue reaches a terminal status (including a catch-up sweep for issues closed before this change) > - The benefit is that interaction cards now faithfully reflect reality: only genuinely actionable requests stay pending, and creators can retract requests that events have overtaken ## Linked Issues or Issue Description Fixes #5787 Refs #7403 Related prior PRs found while searching for duplicates (all overlap partially; none combine both lifecycle paths or the route-level authorization used here): #6709 and #7312 (creator-withdraw attempts), #8169 (terminal expiry), #8081 and #5137 (generalized cancel/expire endpoints), #6094 (stale confirmation auto-resolve). Related merged context: #9568 (agent cancel for ask_user_questions), #10119 (tolerating legacy `withdrawn_by_creator` result outcomes — the reader side of the outcome this PR writes). ## What Changed - New route `POST /issues/:id/interactions/:interactionId/withdraw` that resolves a `pending` interaction to status `withdrawn` with a structured result (`outcome: "withdrawn"`, optional trimmed `reason`), stamps `resolvedBy*`/`resolvedAt`, touches the issue, logs activity, and emits resolved-interaction telemetry - Withdrawal authorization: board users, the interaction's creator agent, or the issue's current assignee agent (assignees additionally pass the standard issue-mutation gate); task-watchdog runs are explicitly rejected, and authorization-boundary plus low-trust control-plane checks apply - Withdrawing an already-resolved interaction returns `409`; unknown/cross-issue/cross-company interaction ids return `404` - New service method `expirePendingInteractionsForTerminalIssue`: when an issue transitions to a terminal status, all of its `pending` interactions are resolved to `expired` with `outcome: "issue_closed"`, guarded by a `status = 'pending'` predicate so concurrent resolutions are not overwritten - The same expiry runs as a catch-up when interactions are listed on an already-terminal issue, so cards stranded by issues closed before this change also get cleaned up; expired request_confirmations are logged with a distinguishing source - Shared package: new `withdrawIssueThreadInteractionSchema` validator, `WithdrawIssueThreadInteraction` type, and `withdrawn` / `issue_closed` result-outcome support for all interaction kinds (kind-aware result shapes for `ask_user_questions` and `request_item_verdicts`) - UI helper `ui/src/lib/issue-thread-interactions.ts` recognizes the new outcomes for card rendering - Docs: bundled skill API reference updated with the withdraw endpoint - Review follow-up: terminal expiry moved from the HTTP route hooks into `issueService.update`'s status-transition block, so direct service callers (tree control, recovery, pipelines, status cards) expire pending cards too; the list-endpoint catch-up remains for issues closed before this change - Review follow-up: withdrawing or issue-close-expiring a `request_confirmation` also settles its linked `tool_action_requests` row (withdraw -> `cancelled`, issue closed -> `expired`), so a parked tool call cannot stay approvable after its card is gone - Review follow-up: interaction cards render dedicated copy for the new outcomes ("Withdrawn" with the reason, "Expired when issue closed") instead of falling through to superseded-by-comment / stale-target variants; withdrawn plan reviews badge as "Withdrawn" rather than "Changes requested" ## Screenshots Card states rendered from a local ux-lab harness with mocked data ([full gallery](https://pages.paperclip.ing/pr-10251-interaction-withdrawal-cards/)): | Light | Dark | | --- | --- | |  |  | ## Verification - `pnpm --filter @paperclipai/shared build` — clean tsc - `cd server && npx vitest run src/__tests__/issue-thread-interaction-routes.test.ts` — 22 tests pass, including new coverage for: creator-agent withdraw success, non-creator/non-assignee agent 403, watchdog-run 403, double-withdraw 409, and board-user withdraw - `cd server && npx vitest run src/services/issue-thread-interactions.test.ts` — 4 tests pass, including terminal-issue expiry writing `issue_closed` results and leaving already-resolved interactions untouched - `cd ui && pnpm typecheck` — clean - `cd server && npx vitest run src/__tests__/issues-service.test.ts` — includes a new embedded-Postgres test proving a direct `issueService.update` terminal transition expires pending interactions and writes the activity-log entry - `cd ui && npx vitest run src/components/IssueThreadInteractionCard.test.tsx` — 32 tests, including new coverage for withdrawn / issue-closed confirmation and question cards - `cd server && npx tsc --noEmit` — matches the pre-existing repo error baseline exactly (no new errors) - Manual: `POST /issues/:id/interactions/:interactionId/withdraw` with `{"reason":"superseded"}` as the creator agent resolves the card to `withdrawn`; closing an issue with a pending confirmation flips it to `expired` with `outcome: "issue_closed"` ## Risks - Interactions on terminal issues now auto-expire (including retroactively via the list-time catch-up), so consumers that expected to resolve a pending interaction on a closed issue will get `409`; this is the intended semantics and matches how the attention feed already wants to treat dead cards - New result outcomes (`withdrawn`, `issue_closed`) are written to stored results; readers were already made tolerant of these outcome strings in #10119, so mixed-version reads are safe - No schema/migration changes; per-row conditional updates (`status = 'pending'`) avoid clobbering concurrent resolutions - Withdrawal is a new mutation surface, but it is strictly narrower than existing resolve paths (board, creator, or assignee only; watchdog runs blocked) ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic Mythos-class tier) with extended thinking and agentic tool use (Claude Code harness); commit authored in a Paperclip-managed engineering session. ## 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>canary/v2026.728.0-canary.0 |
||
|
|
a3b293e26d |
perf(adapter-utils): parallelize the two Daytona sandbox bridge setups (#10334)
## Thinking Path > - Paperclip runs AI-agent work through adapter-backed execution paths. > - Sandbox-backed local adapters pay startup overhead in two host-side bridge setups. > - Those setups were happening serially even though most of the work is independent. > - The remaining dependency is only the merged env that must reach the process-session launch. > - This pull request overlaps the independent setup work while preserving that launch-time dependency. > - The benefit is lower end-to-end startup latency without changing execution semantics. ## Linked Issues or Issue Description No public GitHub issue exists for this change. Problem / motivation: - Sandbox-backed local adapter startup waited for two largely independent bridge setups in series, so users paid roughly the sum of both setup times. - The only hard dependency is the merged Paperclip env that must reach the process-session launch. Proposed solution: - Start the paperclip callback bridge and the process-session bridge concurrently. - Keep the env merge as the single sequencing point before process-session launch. - Stop whichever bridge started if either startup path fails. - Keep the concurrent bridge telemetry duration-only so shared runner counters are not double-counted. Alternatives considered: - Keep the bridges serial, which preserves the current telemetry shape but leaves the startup latency unchanged. - Move env merging earlier, which would complicate launch ordering and risk changing runtime semantics. Roadmap alignment: - This is the approved Daytona start-speedup work, focused on bridge startup concurrency rather than broader runtime behavior. ## What Changed - Started the paperclip callback bridge and the process-session bridge concurrently in `execute.ts`. - Added a memoized env finalizer so the process-session launch still waits for the merged paperclip env at the correct moment. - Updated `execution-target.ts` so the process-session bridge can accept a deferred env resolver and consume it only at launch time. - Added tests that cover the overlapped launch path and the failure-cleanup path when one bridge start fails. ## Verification - `pnpm --filter @paperclipai/adapter-utils exec vitest run src/acpx-engine/execute.test.ts` - `pnpm --filter @paperclipai/adapter-utils test` - `pnpm --filter @paperclipai/adapter-utils exec tsc --noEmit` - `git log --oneline origin/master..origin/perf/parallelize-daytona-bridge-setups` - `git diff --stat origin/master...origin/perf/parallelize-daytona-bridge-setups` ## Risks - A regression in the launch-time env merge could change what the process-session bridge sees at startup. - The concurrent start/cleanup logic could leak a bridge if the stop paths were incorrect, which is why the failure cleanup test matters. - This is low-to-moderate risk because the change is isolated to adapter-utils startup plumbing and is covered by targeted tests. ## Model Used OpenAI Codex, GPT-5, tool-using code execution mode. ## 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 - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.727.0-canary.3 |
||
|
Devin Foley
|
273315a4d0 |
feat(server): provision managed sandbox environments from the managed config (#10324)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Hosted/managed deployments configure instances entirely from the control plane: `PAPERCLIP_MANAGED_CONFIG` already delivers feature flags and `plugins.autoInstall` (bundled sandbox provider plugins), parsed fail-closed at boot > - A plugin alone is not usable for execution: runs need an instance-level `driver: "sandbox"` environment row pointing at the provider, and today only Kubernetes has a boot path for that (`PAPERCLIP_EXECUTION_MODE` → `ensureKubernetesEnvironment`); every other provider requires a manual product-API call the control plane cannot make on a managed instance > - Adding one `ensureXxxEnvironment` per provider would multiply near-identical boot hooks and env-var surfaces > - This pull request generalizes the existing Kubernetes machinery: the managed-config document gains an optional `environments` section that declares a sandbox environment for any bundled provider, ensured idempotently at boot by a provider-agnostic service function (the Kubernetes hook becomes a thin wrapper over it) > - The benefit is that a managed fleet can provision any sandbox provider (Daytona, Modal, E2B, …) purely from configuration — no per-provider code, no manual API calls, no secrets in the document — while self-hosted behavior is untouched ## Linked Issues or Issue Description No public issue exists. Refs #10157 (the cloud image variant that bundles sandbox provider plugins — this PR is the configuration half that makes an installed provider usable). **Problem (feature-request shape):** on a managed instance the control plane can auto-install a bundled sandbox provider plugin via `PAPERCLIP_MANAGED_CONFIG.plugins.autoInstall`, but cannot create the environment row that makes the provider schedulable. The only boot-time environment provisioning is Kubernetes-specific (`PAPERCLIP_EXECUTION_MODE=kubernetes` + `PAPERCLIP_K8S_*`). A generic, config-driven path is needed so any bundled provider can be provisioned without per-plugin code or manual API calls. ## What Changed - `server/src/services/managed-config.ts`: optional `environments` top-level section — `[{ name, description?, provider, config? }]` — validated fail-closed: unknown keys, more than one entry (the DB permits exactly one Paperclip-managed sandbox row, `environments_managed_sandbox_idx`), a `provider` not present in `plugins.autoInstall`, `config.provider`, or secret-looking config keys at any depth (`api_key`/`token`/`secret`/`password`/`credential`) all refuse startup. Absent section ⇒ `environments: []`, so pre-section documents keep booting newer builds. - `server/src/services/environments.ts`: new provider-agnostic `ensureManagedSandboxEnvironment({ name, description?, provider, config?, extraMetadata? })` — idempotently owns the single managed sandbox row: refreshes name/description/config each call, adopts the slot across provider switches (dropping the stale `managedKubernetesSandbox` marker), adopts a same-name unmanaged sandbox row (stamping it managed) instead of colliding on `environments_name_idx` every boot, and falls back to keeping the current name if the desired name belongs to a different row. `ensureKubernetesEnvironment` is now a thin wrapper that pins `provider: "kubernetes"` and stamps the legacy marker. - `server/src/services/managed-environments.ts` (new): `applyManagedEnvironments` boot step — no-op for self-hosted/empty; throws (fail startup) when `PAPERCLIP_EXECUTION_MODE` is also set, since both would own the same managed sandbox row; otherwise ensures each declared environment fail-safe per entry (log + continue boot, matching bundled-plugin provisioning posture). - `server/src/index.ts`: runs the new boot step right after the execution-policy bootstrap, before the heartbeat resumes queued runs. - `server/src/services/index.ts`: exports `applyManagedEnvironments` and `ManagedEnvironmentSpec`. - Secrets stay out of the document by construction: provider credentials reach managed instances only as process env vars (each provider's documented fallback, e.g. `DAYTONA_API_KEY` for the Daytona plugin). ## Verification ```sh cd server pnpm exec tsc --noEmit -p tsconfig.json pnpm exec vitest run \ src/__tests__/managed-config.test.ts \ src/services/managed-environments.test.ts \ src/services/execution-policy-bootstrap.test.ts \ src/__tests__/environment-service.test.ts \ src/__tests__/environment-instance-routes.test.ts \ src/__tests__/environment-routes.test.ts \ src/__tests__/plugin-install-guard.test.ts \ src/__tests__/environment-execution-target.test.ts \ src/__tests__/instance-settings-managed-overlay.test.ts \ src/__tests__/bundled-plugins.test.ts ``` All pass locally (typecheck clean; environment-service suite runs against embedded Postgres and exercises the refactored Kubernetes wrapper plus the new generic ensure: create/refresh, provider switch, unmanaged-row adoption, name-conflict fallback). New tests cover the parser (12 cases incl. secret-key rejection at depth) and the boot step (no-op, mutual exclusion, pass-through, fail-safe). ## Risks - **Self-hosted: none intended.** Without `PAPERCLIP_MANAGED_CONFIG` nothing new executes; the `PAPERCLIP_EXECUTION_MODE=kubernetes` path is regression-covered by the existing bootstrap/service/route suites (all green). - **Behavioral shift in `ensureKubernetesEnvironment` (deliberate):** it now also refreshes `name`/`description` to their managed defaults each boot (desired-state semantics, same as config today) and adopts a `managedByPaperclip` sandbox row that lacks the Kubernetes marker — previously that state made the ensure throw every boot. - **New startup failure modes are all explicit misconfigurations** (malformed section, provider not auto-installed, secret in config, execution-mode conflict) and fail with precise errors; DB-side ensure failures never block boot (fail-safe per entry, logged). - No migrations; no API surface changes. ## Model Used Claude Fable 5 (Anthropic, model ID `claude-fable-5`) with extended thinking and tool use, driving the change end-to-end inside a Claude Code / agent-harness session (code, tests, and verification runs). ## 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 (the managed-config module header is the contract doc) - [x] I have considered and documented any 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 mergecanary/v2026.727.0-canary.2 |
||
|
|
197718bc00 |
feat(acpx): per-step round-trip + provider-latency attribution for sandbox startup (#10222)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Sandbox-backed runs need more precise startup observability so operators can see where time is spent before an adapter is invoked > - Aggregate startup timing hides which boundary is actually slow, especially in remote execution where the bottleneck can move between host round-trips, provider-boundary latency, and handshake phases > - This pull request keeps the existing startup timing channel additive while attributing the latency to the specific startup steps that caused it > - The benefit is better diagnosis of sandbox startup regressions without changing control flow or introducing a schema migration ## Linked Issues or Issue Description Refs: #10204 This PR extends the existing sandbox run-startup timing observability with per-step round-trip and provider-latency attribution for the Daytona startup path. It keeps the event payload additive and free-form, and it leaves the control flow, database schema, and external adapter interfaces unchanged. ## What Changed - Added per-step round-trip counting for the host-to-sandbox execute seam - Added provider-boundary duration accumulation for the Daytona execute and re-fetch steps - Split the ACP handshake timing into `createRuntimeMs` and `ensureSessionMs` while preserving the warm-handle skip - Kept the startup timing payload additive and did not add a schema migration ## Verification - `adapter-utils` acpx-engine and startup-timing suites: pass - Daytona plugin suite: pass with mocked SDK and injected-clock duration assertions - `server` environment-execution-target suite: pass - `tsc --noEmit` for adapter-utils and server: pass - Git validation: fetched `origin/feat/sandbox-start-step-timing-attribution`, confirmed it matches the authorized submit SHA `53c573266e618af05c57a0720aaa9d9e0452de61`, and confirmed the branch contains only the expected commit on top of `origin/master` - Searched GitHub for duplicate or related PRs/issues; found one closely related merged PR and no open duplicate on this branch - Checked `ROADMAP.md`; the broad sandbox-agent roadmap section does not call out this specific startup-timing attribution work as a duplicate ## Risks - Low risk: the change is additive and only enriches existing timing data - Downstream consumers that assume aggregate-only startup timing may need to tolerate the additional per-step fields - The finer spawn/initialize/session split remains a follow-up in the external ACP client because that hook is not available here yet ## Model Used OpenAI GPT-5, tool-using coding agent ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.727.0-canary.1 |
||
|
DottaandPaperclip
|
aed4478c81 |
fix(pr-gardening): scope runs to instance-authored PRs (#10323)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies > - Maintainers use the pr-gardening skill to keep referenced pull requests reviewable and moving toward merge > - The skill previously treated every recently referenced repository PR as owned work, including community PRs and stale references > - That oversized scope caused noisy reports, capped-search failures, and follow-up actions aimed at PRs this Paperclip instance should not manage > - The workflow also stopped at reminders instead of dispatching the repository's standard PR-preparation process > - This pull request scopes gardening to the authenticated instance identity by default and makes exclusions explicit and inspectable > - The benefit is a smaller, ownership-correct queue that automatically routes actionable PRs through the established preparation workflow ## Linked Issues or Issue Description No public issue exists for this maintenance fix, so the bug report is included inline. ### Pre-submission checklist - [x] I searched existing open and closed issues and found no duplicate. - [x] The behavior reproduces on the current `master` branch. - [x] The behavior originates in Paperclip's repository skill, not an adapter, provider, or local configuration. ### What happened? The `pr-gardening` skill included community-authored and stale pull requests in its actionable candidate set, aborted when issue-to-PR extraction hit its cap, and only notified assignees rather than dispatching the standard PR-preparation workflow. ### Expected behavior By default, gardening should act only on PRs authored by the current GitHub identity, report excluded community and stale PRs explicitly, tolerate capped match sets, and dispatch actionable PRs through `/prepare-paperclip-pr`. Operators should retain explicit overrides for broader author scopes. ### Steps to reproduce 1. Run Stage A against issue history containing recently referenced PRs from both the authenticated operator and community contributors. 2. Include an issue whose PR-reference extraction reaches the configured match cap and an open PR with no activity inside the configured window. 3. Observe that the prior workflow admits non-owned and stale PRs, aborts on the capped extract, and leaves Stage C at assignee reminders. ### Paperclip version or commit Reproduced on upstream `master` at `2568bdecc4577c60d76d58a45c5eaf3dc58f7e13`. ### Deployment mode Local repository skill execution. ### Installation method Built from source. ### Agent adapter(s) involved Not adapter-specific; this is a repository maintenance skill. ### Database mode Not database-related. ### Access context Agent execution using the repository's authenticated GitHub CLI identity. ### Node.js version Current repository development environment. ### Operating system Linux. ### Relevant logs or output Live verification before the fix showed 264 community PRs entering discovery scope. The corrected discovery retained 54 candidates, all authored by `cryppadotta`. ### Relevant config Default author resolution via `gh api user --jq .login`; no secret or user-specific configuration is included. ### Additional context The fix retains `--authors` and `--include-community` overrides for intentionally broader maintenance runs. ### Privacy checklist - [x] I reviewed all included output and configuration details for secrets and PII. ## What Changed - Resolve the default author allowlist from the authenticated `gh` login, with `--authors` and `--include-community` overrides. - Default the activity window to 14 days and record community-authored and stale PRs in explicit dropped lists. - Preserve capped issue-extract match sets with warnings instead of aborting discovery. - Add PR author and a one-line purpose summary to readiness data and rendered reports. - Rewrite Stage C to dispatch `/prepare-paperclip-pr` for PRs that need gardening. - Expand the focused Node test suite to cover the new scoping, stale-drop, cap, summary, reporting, and guardrail behavior. ## Verification - `node --test .agents/skills/pr-gardening/scripts/pr-gardening.test.mjs` — 15/15 passing, including contributor-controlled Markdown escaping. - `git diff --check origin/master...HEAD` — clean. - Live discovery verification excluded 264 community PRs and retained 54 candidates, all authored by `cryppadotta`. ## Risks - Low-to-moderate behavioral risk: default candidate scope is intentionally narrower; operators who want community PRs must opt in with `--include-community` or provide `--authors`. - The authenticated `gh` login must be available unless an explicit author override is supplied. - No database, API, UI, migration, workflow, or dependency-lock changes. > 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 using GPT-5.4 with reasoning, repository tool use, shell execution, GitHub CLI access, and focused test execution. The original implementation commit also records Claude Fable 5 assistance. ## 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>canary/v2026.727.0-canary.0 |
||
|
DottaandPaperclip
|
2568bdecc4 |
fix(adapter-utils): keep sandbox proxy sockets within Linux path limit (#10221)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI agents for work > - Local process adapters can enforce network allowlists through a Unix-socket proxy inside the Linux sandbox > - The proxy socket was created under `os.tmpdir()`, which can be a deeply nested run-specific directory > - Linux Unix-domain socket paths are limited to 107 usable bytes, so deep temporary paths can be silently truncated during bind > - A truncated proxy socket resets every confined outbound connection, including the model provider API, before the agent can do work > - This pull request creates proxy sockets under the short `/tmp` path when possible and validates the path length before bind > - The benefit is reliable sandboxed egress under deep `TMPDIR` values and an explicit error instead of an opaque connection-reset storm ## Linked Issues or Issue Description ### Pre-submission checklist - [x] I searched existing open and closed issues and this is not a duplicate. - [x] I can reproduce this on upstream `master`. - [x] I confirmed the error originates in Paperclip's local-process sandbox proxy. ### What happened? Sandboxed local-process agents using `networkScope: "allowlist"` could lose all proxied egress when `TMPDIR` was deeply nested because `proxy.sock` exceeded Linux's Unix socket path limit. The truncated bind surfaced as repeated connection resets, including for provider API traffic. ### Expected behavior Proxy creation should use a Linux-safe short path and fail explicitly if no safe socket path can be created. ### Steps to reproduce 1. Set `TMPDIR` to a path long enough that `<TMPDIR>/paperclip-network-sandbox-XXXXXX/proxy.sock` exceeds 107 bytes. 2. Build or run a local-process sandbox with `networkScope: "allowlist"`. 3. Make an HTTP or HTTPS request through the generated sandbox proxy. 4. Observe connection resets from the overlong Unix socket path on affected code. ### Paperclip version or commit Upstream `master` before this change. ### Deployment mode Other — Linux local-process adapters using Bubblewrap network allowlisting. ### Installation method Built from source. ### Agent adapter(s) involved Codex and any other local-process adapter using the shared sandbox utility. ### Operating system Linux. ### Additional context GitHub search found no duplicate public issue or pull request for this defect. ## What Changed - Add a Linux Unix-socket byte-length guard that reports the unsafe path before binding. - Create network proxy temporary directories under `/tmp` first, with `os.tmpdir()` as a validated fallback. - Use the safe temporary-directory helper at both allowlist proxy creation sites while preserving trusted URL handling. - Add regression coverage that sets a deliberately deep `TMPDIR` and verifies the working socket remains within 107 bytes under `/tmp`. ## Verification - `node /srv/paperclip/home/paperclipai/paperclip/node_modules/vitest/vitest.mjs run packages/adapter-utils/src/local-process-sandbox.test.ts` — 8 passed, 4 environment-gated tests skipped. - `git diff --check origin/master...HEAD` — passed. - Greptile Review — passed after reviewing 2 files with 0 comments and no unresolved threads; this repository integration did not emit a separate numeric confidence score. - Full GitHub CI matrix — passed after one rerun of an unrelated ACPX `ENOTEMPTY` cleanup flake. - Package typecheck was attempted, but the existing shared install cannot resolve `acpx/runtime`; the failure is outside the changed files and is expected to be covered by CI's clean dependency install. ## Risks - Low risk: the change is limited to Linux sandbox proxy temporary-directory selection and validation. - Systems without a writable `/tmp` fall back to `os.tmpdir()` only when the resulting socket path is safe; otherwise startup now fails loudly instead of producing connection resets. - No schema, API, UI, migration, or documentation behavior changes. > 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.3-codex`, tool-enabled coding agent with managed reasoning and code execution; context-window size is 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 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>canary/v2026.726.0-canary.0 |
||
|
Devin FoleyandPaperclip
|
d1b9448b57 |
fix(server): stamp the real build version into images instead of the package.json placeholder (#10257)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work; it ships as a Docker image that self-hosters and managed deployments run. > - The server resolves its own version at runtime in `server/src/version.ts` (`resolveServerVersion()`), which feeds analytics and the server debug panel. > - That resolver derives the real version from `git describe`, and falls back to `server/package.json`'s `version` when git isn't available. > - But `server/package.json`'s version is a static placeholder — CI only stamps the real CalVer at publish, so in source it is never the real version (currently `0.3.1`). > - A Docker image has no `.git` (it's dockerignored), so `git describe` can't run inside it. Every image therefore falls back to the placeholder and reports `0.3.1` in analytics and the debug panel, regardless of which commit it was built from. > - This PR computes the real version once on the CI build runner (where `.git` and tags exist), bakes it into the image, and has `resolveServerVersion()` prefer that stamp when `git describe` is unavailable. > - The benefit: self-hosted and cloud images report their true version instead of a misleading placeholder, with no change to dev checkouts, `git describe`-based resolution, or local `docker build`. ## Linked Issues or Issue Description No public issue exists — describing the bug inline (per the bug report template). **What happened?** Docker images built from `master` (and release tags) report the server version as the `0.3.1` placeholder in analytics and the server debug panel, instead of the real version of the commit the image was built from. **Expected behavior** An image reports the real version of its build commit (e.g. `2026.722.0+51.git.<sha>`), so operators can tell which build is running. **Steps to reproduce** 1. Build the server Docker image from any `master` commit (the `Docker` workflow, `production` target). 2. Run the image and open the server debug panel (or inspect the version reported to analytics). 3. Observe the version is `0.3.1` rather than the commit's real version. **Root cause** `resolveServerVersion()` derives the real version from `git describe`, but the image has no `.git` (dockerignored), so it falls back to `server/package.json`'s `version` — a static placeholder CI only replaces with the real CalVer at publish time. Nothing bakes the real version into the image. **Paperclip version or commit:** reproduces on `master` (`4c55f0d8`) and any published image. **Deployment mode:** self-hosted and managed (both the `production` and `-cloud` images). **Installation method:** Docker image (`ghcr.io/paperclipai/paperclip`). **Related PRs (dedup search):** #9103 (merged — added the `git describe`-based source-install resolution this builds on) and #9637 (closed). Neither bakes a version into the image; this PR closes that gap. No duplicate found. ## What Changed - **`.github/workflows/docker.yml`** — checkout with full history + tags (`fetch-depth: 0`), and a new `Compute build version` step that runs `git describe --tags --match 'v*' --long --dirty` on the pristine runner checkout. The result is passed as a `PAPERCLIP_BUILD_VERSION` build-arg to both the `production` and `-cloud` image builds. - **`Dockerfile`** — the `production` stage takes an `ARG PAPERCLIP_BUILD_VERSION` (default empty) and bakes it into the runtime `ENV`; the `cloud` stage inherits it via `FROM production`. - **`server/src/build-version.ts`** (new) — `readBuildVersion()` / `parseBuildVersion()`, mirroring `build-commit.ts`: reads `PAPERCLIP_BUILD_VERSION` (or a `.paperclip-build-version` file) as a single-token stamp. - **`server/src/version.ts`** — `resolveServerVersion()` prefers the baked build version when `git describe` is unavailable, parsing it with the same rules as a live checkout (`parseGitDescribeVersion`), and falling through to the existing `build-commit` stamp and package version when unset. A live checkout's `git describe` still wins over any stamp. - Tests for the new behavior and the precedence. ## Verification - `pnpm --filter @paperclipai/plugin-sdk ensure-build-deps && tsc --noEmit` in `server/` — clean. - `vitest run server/src/__tests__/version.test.ts server/src/__tests__/build-version.test.ts` — **23 tests pass**, covering: stamped version used when git describe fails, stamp parsed to real CalVer, stamp preferred over the build-commit fallback, on-tag stamp collapses to the release version, a pre-resolved stamp used verbatim, and a live git describe still winning over a stamp. - `git describe --tags --match 'v*' --long` for this commit → `v2026.722.0-51-g<sha>`, which `resolveServerVersion()` reports as `2026.722.0+51.git.<sha>` — no longer `0.3.1`. - Not run locally: the full multi-arch image build (CI-only). The workflow change is verified by inspection; the version is computed on the pristine checkout before any lockfile refresh, so it carries no spurious `-dirty`. ## Risks Low. Additive and image-only: - No runtime behavior changes for dev checkouts (git describe still primary and wins over any stamp) or for local `docker build` (empty arg → server keeps its existing fallbacks). - Not a breaking change; no schema or API surface. The stamp is informational (version reporting only). - `fetch-depth: 0` makes the release-image checkout fetch full history/tags — a modest cost on a workflow that already runs at release cadence with a 60-minute budget. - Rollback: revert the commit; images simply return to reporting the placeholder. ## Model Used Claude Opus 4.8 (`claude-opus-4-8`, 1M-context variant), extended thinking, with tool use / code execution — agentic edits, `tsc` + `vitest` runs, and a `git describe` resolution check. ## 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 (bugfix, not core feature work) - [x] I have searched GitHub for duplicate or related PRs and linked them above (#9103, #9637 — related, not duplicates) - [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 (`fix/build-version-stamp`) 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 (no user-facing docs affected; behavior is documented inline in `version.ts` / `build-version.ts` and the workflow/Dockerfile) - [x] I have considered and documented any 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 Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.725.0-canary.3 |
||
|
DottaandPaperclip
|
4c55f0d8da |
fix(inbox): hide external object summaries (#10020)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The inbox helps operators scan and act on tasks that need attention > - Inbox task rows currently include external-object summary markers alongside the core task information > - Those markers add a column of visual noise that is not needed for inbox triage > - External-object data must remain available to the inbox filters even when the row marker is removed > - This pull request stops passing external-object summaries into inbox rows and adds regression coverage > - The benefit is a cleaner inbox while preserving external-object filtering behavior ## Linked Issues or Issue Description - Refs #4556 - **Problem:** Inbox task rows display external-object summary markers that operators do not need for triage. - **Expected behavior:** Inbox rows omit the external-object marker, while filters that depend on external-object summaries continue to work. ## What Changed - Removed the external-object summary prop from inbox task rows. - Added a regression test that provides external-object summary data and confirms the inbox row does not render its marker. - Kept external-object summary loading intact for inbox filtering. ## Verification - `pnpm exec vitest run ui/src/pages/Inbox.test.tsx` — 18 tests passed. - `pnpm check:token-gates` — reproduces five pre-existing `#9627` color-literal violations; this PR adds no token values or new gate violations. ## Risks - Low risk: the change removes one optional presentation prop from the inbox row call site and leaves filtering data flow unchanged. - Regression coverage verifies summary data no longer produces the removed inbox marker. > 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.4, tool-enabled coding agent with shell and code execution; reasoning enabled; context-window size 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 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>canary/v2026.725.0-canary.2 |
||
|
DottaandPaperclip
|
c481be44e3 |
fix(task-watchdogs): deduplicate unchanged stopped-state wakes (#10207)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Task watchdogs review issue subtrees when no run or queued wake keeps work live > - Pending human interactions and approvals are valid stopped states that still need one watchdog review > - The existing fingerprint included volatile activity timestamps, so unchanged stopped trees could wake repeatedly after comments, documents, work products, or sibling completions > - This pull request fingerprints only review-material leaf and wait state, persists the reviewed snapshot, and suppresses shrink-only repeats > - The benefit is one review per materially new stopped state without weakening liveness classification or hiding human waits ## Linked Issues or Issue Description ### What happened? Task-watchdog stop fingerprints changed for metadata-only activity and completed siblings, producing duplicate wakes after an unchanged stop had already been reviewed. ### Expected behavior Pending interactions and approvals remain classified as stopped, but a reviewed stopped state only wakes again when waits, non-terminal leaves, status, assignment, or blockers gain material changes. ### Steps to reproduce 1. Review a stopped watched subtree with a pending human wait or multiple non-terminal stopped leaves. 2. Add only comment/document/work-product activity, or complete one stopped sibling without changing the wait set. 3. Observe a duplicate wake from the timestamp-heavy fingerprint. Related public work: Refs #9452 for overlapping task-watchdog service edits and #10043 for related no-op fingerprint suppression. ## What Changed - Added fingerprint v2 over non-terminal material leaves plus subtree-wide pending wait ids, excluding volatile timestamps while retaining them in wake context. - Added nullable observed/reviewed JSONB stop snapshots and shrink-only reviewed-state suppression with legacy exact-fingerprint fallback. - Added pending interaction kinds and approval ids to watchdog wake context, review comments, and comment metadata. - Added classifier and scheduler coverage for waiting-leaf liveness, metadata stability, sibling shrink suppression, material changes, snapshot promotion, legacy rows, and unchanged idempotency keys. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/task-watchdogs-classifier.test.ts src/__tests__/task-watchdogs-scheduler.test.ts` — 2 files, 36 tests passed. - `pnpm --filter @paperclipai/server typecheck` — passed. - `git diff --check origin/master...HEAD` — passed. ## Risks - Fingerprint version 2 intentionally re-fingerprints every currently stopped watched tree once after deployment, causing a one-time wake burst before the new reviewed snapshots are established. - Migration `0191_task_watchdog_stop_snapshots.sql` only adds two nullable JSONB columns with no backfill; legacy rows continue exact-fingerprint behavior until a post-deploy review promotes a snapshot. - PR #9452 edits the same service file; whichever lands second may need a trivial rebase. > 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, exact model ID `gpt-5.6-sol`, high reasoning mode, with repository tool use and code execution. The runtime did not expose a context-window size. ## 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 - [ ] 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>canary/v2026.725.0-canary.1 |
||
|
DottaandPaperclip
|
4e00818574 |
fix(runtime): support in-place workspace realization (#10230)
## Thinking Path > - Paperclip is the control plane people use to coordinate AI agents and their execution environments. > - Environment realization decides where an agent runs and which filesystem and toolchain are authoritative. > - Copy-based realization is unsafe for container-anchored tasks because absolute paths such as `/app` can point outside the synchronized tree and task-specific binaries may be absent. > - That mismatch can let an agent successfully verify work in a phantom writable path while sync-back silently discards the result. > - Existing task environments already provide the authoritative filesystem and toolchain, so they should be executed in place rather than copied. > - Copy mode still needs explicit confinement rules so aliases target the synchronized workspace and unsynchronized writable paths fail visibly. > - This pull request adds typed realization metadata, propagates the authoritative root through orchestration, and teaches Codex to honor it. > - The benefit is that container-anchored tasks operate on verifier-visible state with the intended tools, while copy mode remains safe and backward compatible. ## Linked Issues or Issue Description No public GitHub issue exists for this defect. GitHub duplicate searches for in-place execution, workspace realization, and authoritative workspace roots found no related pull request to link. ### What happened? Environment-backed agent runs were always realized through a copied workspace. Tasks anchored to absolute container paths could therefore write outside the synchronized tree, and task-provided toolchains were unavailable in the copy. A run could report success even though sync-back discarded its output. ### Expected behavior Existing task environments should run against their real authoritative root and toolchain. Copy-mode runs should map declared absolute aliases into the synchronized tree and reject writable paths that cannot be restored. ### Steps to reproduce 1. Run a Codex task environment whose required files live under `/app` or `/workspace` and whose required binary exists only in the task container. 2. Observe that copy realization changes the effective filesystem/toolchain or permits writes outside the synchronized root. 3. Complete and verify the task inside the agent sandbox. 4. Observe that the verifier cannot see out-of-tree artifacts or that task-specific commands were unavailable. ### Reproduction context - Paperclip commit: `3a16b91217483d2c233926de5b7f7bc3a1077924` - Deployment: built from source in a task-container execution environment - Adapter: Codex local - Database: not database-related - Access context: agent execution ## What Changed - Added typed `copy | in_place` workspace-realization metadata, authoritative roots, confined aliases, and outbound restore paths to shared execution-target contracts. - Selected in-place realization for existing task environments and skipped archive prepare/restore when the authoritative environment is used directly. - Propagated the authoritative root into adapter context so Codex uses it for cwd and `PAPERCLIP_WORKSPACE_*` semantics, including ACP execution. - Bound copy-mode aliases such as `/app` to the synchronized workspace and rejected writable out-of-tree paths without explicit restore mappings. - Added focused regression coverage while preserving existing copy-mode archive restore behavior. ## Verification - `pnpm --filter @paperclipai/shared typecheck` — passed. - `pnpm exec vitest run packages/adapter-utils/src/local-process-sandbox.test.ts packages/adapters/codex-local/src/server/acp.test.ts packages/adapters/codex-local/src/server/execute.remote.test.ts server/src/__tests__/environment-run-orchestrator.test.ts` — 48 passed, 4 skipped. - `pnpm -r typecheck` — passed. - `env -u AWS_ACCESS_KEY_ID -u AWS_SECRET_ACCESS_KEY -u AWS_SESSION_TOKEN pnpm test:run` — passed across all general and serialized Vitest shards. - `pnpm build` — passed. - Codex `k=1` acceptance run completed July 24, 2026 at 23:54:30 UTC with 4 completed, 0 exceptions, and mean reward 1.0: `build-cython-ext`, `openssl-selfsigned-cert`, `prove-plus-comm`, and `sqlite-db-truncate` each received terminal grade 1.0 against real task-environment paths and toolchains. ## Risks - In-place mode deliberately exposes the authoritative task root to the adapter; incorrect environment metadata could point execution at the wrong root. Typed metadata and focused orchestration tests cover selection and propagation. - Copy-mode writable-path validation is stricter and may reject previously accepted unsafe configurations. The rejection is intentional and produces a visible error instead of silently losing output. - The acceptance run is focused on four Codex task-environment workloads, not a broad cross-adapter benchmark. Existing copy-mode archive tests and the full repository suite remain green. > 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 CLI coding agent; exact model ID and context-window size were not exposed to this runtime. Capabilities used: extended reasoning, repository editing, shell execution, test/build execution, Git, GitHub CLI, and Paperclip API tool use. ## 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>canary/v2026.725.0-canary.0 |
||
|
|
cca2806e57 |
test(tool-gateway): make idle-down slot test deterministic via injected clock (#10226)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The server has a gateway layer that coordinates tool execution and runtime slots > - The idle-down test for the local stdio fixture slot was relying on real wall-clock timing > - On slower runners, that made the test nondeterministic because the slot could be reaped before the presence assertion ran > - This pull request switches the test to use the existing injectable clock seam so time only advances when the test says it should > - The benefit is that the idle-down behavior stays covered while the test becomes deterministic and no longer flakes under load ## Linked Issues or Issue Description This PR fixes a flaky gateway test in the server test suite. The `tool-gateway` idle-down scenario was asserting slot presence while also depending on a very short real-time idle TTL and a later sleep-based reap. On loaded runners, the intervening work could exceed the TTL, which caused the slot to disappear early and the assertion to see an empty list. The fix keeps the production code path unchanged and drives the test from the supervisor's existing injectable clock. The test now holds time steady through the presence check, then advances the clock past the idle deadline to trigger the reap deterministically. The original behavioral assertions stay intact: slot reuse, counter increments, metadata, and stop status still get verified. ## What Changed - Replaced the real-time idle-down wait in the `tool-gateway` test with the runtime supervisor's injectable clock seam. - Kept the existing assertions for slot reuse, slot identity, counters, metadata, and stop behavior. - Removed the test's dependency on wall-clock timing so the idle-down path is deterministic under load. ## Verification - Targeted server typecheck passed with `tsc --noEmit`. - `tool-gateway.test.ts` passed in full: 49/49. - The targeted idle-down scenario passed 50/50 in a tight loop with 0 failures after the clock injection change. ## Risks - Low risk: this is a test-only change and does not modify production gateway logic. - The test now exercises the idle-down logic through a controlled clock rather than real elapsed time, which is the point of the fix but does slightly reduce wall-clock realism in the test itself. ## Model Used OpenAI Codex (GPT-5), tool-using coding agent; context window not surfaced in the workspace. ## 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: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.724.0-canary.17 |
||
|
DottaandPaperclip
|
30ff3d7c58 |
feat(routines): expose activity gate API (#9438)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Scheduled routines provide recurring control-plane work without manual intervention > - The new activity gate can suppress scheduled runs when no external work occurred > - The core scheduler and database support landed without a public create/update contract > - Agents, operators, and managed plugins need validated fields plus discoverable semantics to opt in safely > - This pull request exposes the activity gate through routine APIs, revisions, plugin contracts, tests, and skill documentation > - The benefit is backward-compatible control over idle scheduled work without losing activity-triggered follow-up ## Linked Issues or Issue Description - Refs #8534 ## What Changed - Added shared activity-gate policy and scope enums with create/PATCH validation. - Persisted activity-gate fields through routine creation, updates, revision snapshots, pipeline snapshots, and revision restores. - Defaulted legacy revision snapshots during restore and added regression coverage for pre-field snapshots. - Extended managed-plugin routine declarations, production reconciliation, and the SDK test harness to preserve non-default gate settings. - Added end-to-end API coverage for create/PATCH/list/detail round-trips, defaults, and invalid enum rejection. - Documented schedule-only semantics, activity windows, own-run/read-action exclusions, scopes, and an hourly quiet-night watcher example. ## Verification - `pnpm exec vitest run packages/shared/src/validators/routine.test.ts server/src/__tests__/routines-service.test.ts server/src/__tests__/routines-e2e.test.ts` - `pnpm exec vitest run packages/shared/src/validators/plugin.test.ts packages/plugins/sdk/tests/testing-actions.test.ts server/src/__tests__/plugin-managed-routines.test.ts server/src/__tests__/routines-service.test.ts -t 'activity gate|preserves declared activity gate settings|resolves routine agent and project refs'` - `pnpm exec vitest run ui/src/lib/workspace-routines.test.ts ui/src/pages/Routines.test.tsx` - `pnpm --filter @paperclipai/shared typecheck` - `pnpm --filter @paperclipai/plugin-sdk typecheck` - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm check:token-gates` - GitHub CI: all final-head checks green; Storybook visual regression skipped by path rules. - Greptile: 5/5 with no unresolved review threads. ## Risks - Low risk: defaults remain `always` and `company`, preserving existing routine behavior and old revision snapshots. - Managed plugin manifests can now declare the same validated gate settings as the public routine API; omitted values retain core defaults. - Revision snapshots now include the new fields so policy changes are not lost or treated as no-ops during restore. > For core feature work, checked `ROADMAP.md`: this extends the existing Scheduled Routines roadmap item and does not duplicate a separate planned capability. ## Model Used - OpenAI GPT-5.5 via Codex CLI, with repository tool use and code execution; context-window size 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 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>canary/v2026.724.0-canary.16 |
||
|
DottaandPaperclip
|
8f08ec5ce6 |
feat(status-cards): join summary-mentioned issues to watched set (#10205)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Status cards summarize changing company work and watch issues so later changes can produce useful deltas > - A summary can explicitly reference issues that are important to the update even when those issues do not match the card's configured queries > - Previously, those referenced issues were not retained in the watched set, so their later status, assignee, or comment changes could be missed > - The watched snapshot must avoid artificial additions or removals caused only by a summary changing which issues it references > - This pull request resolves issue references when a summary is written, persists them, and joins them to the watched snapshot with stable delta semantics > - The benefit is that status cards continue tracking the exact issues their latest update called out while keeping follow-up updates relevant and non-duplicative ## Linked Issues or Issue Description ### Pre-submission checklist - [x] I have searched existing open and closed issues and this is not a duplicate. - [x] I am on the latest released version of Paperclip (or can reproduce on `master`). - [x] I have confirmed the error originates in Paperclip itself — not in my agent adapter, API provider, or local configuration. ### What happened? When a status-card summary explicitly referenced an issue by identifier or `/issues/<uuid>` URL, that issue was not automatically retained in the card's watched set unless it independently matched a configured query. Later status, assignee, or comment changes to an issue highlighted by the latest update could therefore be omitted. ### Expected behavior References in the latest summary should resolve only within the card's company, appear in dry runs and the watched-issues UI, count and fingerprint like query matches, and enter or leave the watched set without artificial added/removed deltas already represented by the summary change. ### Steps to reproduce 1. Create a status card whose query does not match a second issue in the same company. 2. Write a summary that references the second issue by identifier or issue URL. 3. Inspect the card's watched count or Watched issues tab. 4. Change the referenced issue's status, assignee, or comments and run the next update. 5. Before this change, the referenced issue is absent from the watched snapshot and its later change does not produce the expected delta. ### Paperclip version or commit - Reproduced on `master` before this PR (base commit `762ce5b4ef`). ### Deployment mode - Local dev (`pnpm dev`), built from source. ### Agent adapter(s) involved - Not adapter-specific (core bug). ### Database mode - Embedded Postgres test environment; the schema change uses standard PostgreSQL JSONB. ### Access context - Board (human operator). ## What Changed - Added migration `0191` and schema support for persisted `status_cards.mentioned_issue_ids`. - Resolved summary references by issue identifier or `/issues/<uuid>` URL within the status card's company when summaries are written. - Joined mentioned issues into watched counts and fingerprints so later status, assignee, and comment changes generate normal update deltas. - Suppressed artificial added/removed deltas when the latest summary starts or stops mentioning an issue. - Added `mentionedIssues` to dry-run responses and a “Mentioned in the latest update” group in the Watched issues tab. - Updated the summarizer prompt to explain that referenced issues automatically join the watched set. - Added focused server and UI coverage for reference resolution, snapshot behavior, deltas, API responses, and rendering. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/status-cards.test.ts src/__tests__/status-card-update-engine.test.ts` — 31 tests passed. - `pnpm --filter @paperclipai/ui exec vitest run src/pages/StatusCards/StatusCardTile.test.tsx` — 11 tests passed. - Earlier implementation verification also passed database/shared/server typechecks, UI `tsc -b`, the broader StatusCards UI test set, and embedded-Postgres migration application. ### Visual Verification - Greptile T-Rex ran Playwright browser checks successfully and captured the Status Card drawer Watched tab showing the new “Mentioned in the latest update” grouping: https://app.greptile.com/trex/runs/15796101/artifacts ## Risks - The migration adds a nullable JSONB column and is backward-compatible; existing cards have no mentioned issues until their next summary write. - Reference extraction is company-scoped to prevent cross-company issue association. - Watched counts and future fingerprints change for cards whose latest summaries reference issues; tests cover additions, removals, and suppression of spurious deltas. - This targeted status-card fix does not introduce a new roadmap subsystem or external integration. ## Model Used - Anthropic Claude Fable 5 (Paperclip model alias; exact underlying provider model ID and context window were not recorded in the implementation task metadata), with extended reasoning, tool use, and code execution. - OpenAI Codex coding agent (runtime model identifier and context window not exposed to this task) prepared the PR, rebased the branch, and ran focused verification with terminal tool use. ## 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) - [ ] 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> |
||
|
DottaandPaperclip
|
665408c6d0 |
fix(codex): classify mid-turn harness crashes structurally as retriable infra (#10210)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI agents and their work > - Heartbeat execution relies on adapters distinguishing agent failures from failures in the harness running beneath the agent > - Codex MCP transport crashes can kill the CLI after the JSONL protocol has started but before it emits a protocol-terminal event > - Those interrupted streams were left unclassified, so the control plane terminalized the heartbeat as `heartbeat_failed` / `agent_failure` with no continuation > - Agent-level failure is already expressible through the JSONL protocol via an `error` event, `turn.failed`, or `turn.completed`, so an interrupted nonzero exit can be classified structurally without inspecting unstable error strings > - This pull request reports that shape as `codex_harness_crash` in the `transient_upstream` family and routes it through Paperclip's existing bounded retry and recovery-continuation paths > - The benefit is that transient Codex harness failures recover safely without misclassifying quoted agent output or depending on transport-specific wording ## Linked Issues or Issue Description - **What happened:** Codex MCP transport failures, including rmcp worker death, could terminate the CLI mid-turn after protocol output began but before any terminal JSONL event. The run then became an unclassified terminal heartbeat failure with `continuationCount: 0`; this occurred in 3 of 44 L3 Codex-lane trials during the associated benchmark investigation. - **Expected behavior:** a nonzero Codex exit after the protocol starts but before an `error`, `turn.failed`, or `turn.completed` event should be treated as a harness/infrastructure crash and enter the existing bounded retry policy. - **Why structural classification:** transport error strings vary, and stdout may quote agent output that merely discusses network failures. The protocol boundary identifies whether the agent itself produced a terminal result without regex matching. - **Recovery behavior:** `codex_harness_crash` maps to `errorFamily: transient_upstream`, using the existing `same_session` → `safer_invocation` → `fresh_session` ladder plus the recovery-continuation transient-infrastructure path. - Supersedes the regex-based approach in #10150, which is closed. ## What Changed - Added protocol-state tracking that identifies a nonzero exit after protocol start and before any protocol-terminal event as `codex_harness_crash`. - Propagated the structural classification as `transient_upstream` through the Codex adapter. - Added parse unit coverage, including a faithful crash-shaped stream, without matching stderr transport strings. - Added adapter execution coverage using a fake Codex process that emits a protocol prefix and then dies with the observed rmcp stderr line. - Added heartbeat bounded-retry coverage, including the `errorCode`-only fallback, and recovery-continuation classification coverage. ## Verification - `parse.test.ts` — 16 passed. - `codex-local-execute.test.ts` — 16 passed. - `heartbeat-retry-scheduling.test.ts` — 30 passed. - `service.pause-durability.test.ts` — 6 passed. - Server and Codex adapter TypeScript checks passed. - The branch commit is unchanged from the tested and pushed `88f5464d40` handoff. ## Risks - Low risk: the classification requires a nonzero exit after protocol start and before any protocol-terminal event, so normal agent-declared failures and completed turns keep their existing behavior. - The change intentionally broadens recovery for structurally interrupted Codex runs; bounded retry limits still prevent indefinite continuation loops. - No schema, migration, public API, UI, lockfile, or workflow changes. > 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. The exact runtime model ID and context-window size were not exposed by the execution environment; capabilities used for the implementation included repository analysis, reasoning, code editing, and terminal-based test 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 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) - [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details — the pre-existing, already-pushed branch name was explicitly prescribed for this replacement PR - [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> |
||
|
DottaandClaude Fable 5
|
b996b71a38 |
Deduplicate wake-payload issue descriptions and compact resume deltas (#10216)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Heartbeat wake payloads and the task-context markdown are the two channels that deliver an issue's brief into an agent's prompt > - #10151 fixed wake-prompt-only adapter lanes waking without the issue description by adding it to the structured wake payload > - That left the description delivered twice per prompt on lanes that also inject the task-context markdown, and re-delivered in full on every resume wake, permanently bloating persistent-session context > - This pull request makes the task markdown the single description carrier on lanes that use it, and omits the description from non-assignment resume deltas on all lanes while keeping it for assignment-shaped and recovery wakes > - The benefit is that every lane receives the brief exactly once when it needs it, and long-lived sessions stop re-paying the full brief in tokens on every wake ## Linked Issues or Issue Description Refs #10151 Related prior work: #2883, #8402 (earlier description-delivery attempts referenced by #10151). I searched the PR list for open work on wake-payload description handling and found none besides the merged #10151. **Bug:** After #10151, adapters that inject the `Paperclip task context` markdown (ACPX engine lanes, claude-local CLI, hermes server and gateway) receive the issue description twice in a single prompt — once in the wake prompt's `Issue description:` block and once in the task markdown. Separately, resume deltas re-send the full description (up to 12k characters) on every wake even though the persistent session already received it. **Expected behavior:** The description appears exactly once per prompt on every lane, and resume deltas only carry it when the resuming session may not have seen the brief (assignment-shaped or recovery wakes), leaving an explicit fetch breadcrumb otherwise. **Reproduction:** Wake a claude-local or ACPX agent on an issue with a description and inspect the assembled prompt: the description text appears in both the wake-payload block and the task-context block. Wake the same session again via a comment: the full description is present again in the resume delta. **Affected version:** Current `master` (with #10151 merged). **Deployment mode:** Adapter-backed heartbeat execution, local and sandboxed lanes. ## What Changed - `renderPaperclipWakePrompt` accepts `suppressIssueDescription`; the four task-markdown lanes pass it so the task markdown stays the single, uncapped description carrier there. - Non-assignment resume deltas omit the description and emit `- issue description: omitted from this resume delta; fetch the issue if you need the latest brief`. Assignment-shaped reasons (`issue_assigned`, `issue_reopened_via_comment`, `issue_recovery_action_restored`, `issue_tree_restored`) and recovery wakes still deliver the full brief. - `buildPaperclipTaskMarkdown` gains `includeDescription`; the server now also publishes `context.paperclipTaskMarkdownCompact` (description stripped, directives and wake comment kept), and the new `selectPaperclipTaskMarkdown` helper picks the right variant under the same resume rules, falling back to the full markdown when no compact variant exists (version skew safety). - The wake prompt's description block now carries the same user-authored trust framing the task markdown already had. ## Verification - `npx vitest run packages/adapter-utils/src/server-utils.test.ts packages/adapters/claude-local/src/server/acp.test.ts packages/adapters/codex-local/src/server/acp.test.ts server/src/__tests__/heartbeat-context-summary.test.ts` — 137 tests passed, including new coverage for suppression, resume omission plus breadcrumb, assignment-shaped resume inclusion, compact-variant building, variant selection, and an end-to-end ACPX prompt-assembly test asserting the description appears exactly once on fresh wakes and not at all on comment resumes. - `npx vitest run` in `packages/adapters/hermes` — 59 tests passed, including a gateway execute-level test asserting the brief is sent exactly once on fresh runs and not re-sent on stable-session resumes. - `tsc --noEmit` in `packages/adapter-utils`, `packages/adapters/claude-local`, `packages/adapters/hermes` — clean; `server` matches the `master` baseline exactly (pre-existing plugin-sdk resolution errors only, none in touched files). - Pre-existing failures confirmed identical on clean `master`: claude-local `execute.remote.test.ts` / `test.probe.test.ts`, adapter-utils `mcp-isolation.integration.test.ts` (requires a newer local Claude CLI). ## Risks - Behavioral shift, prompt-only: a resumed session woken by a comment on an issue it never handled (rare — assignment wakes normally precede comment wakes) would not get the inline description; the breadcrumb plus the standard issue-fetch path covers it. - Additive context key (`paperclipTaskMarkdownCompact`); older adapters ignore it and newer adapters fall back to the full markdown when it is absent, so mixed-version deployments degrade to current behavior. - No schema, migration, or API changes; the structured wake-payload JSON shape is unchanged. - Known follow-up deliberately out of scope: openclaw embeds the raw wake-payload JSON (which still contains the description) in prompt text for machine parsing. The hermes-gateway lane is handled: it detects stable-session resumes (issue/agent session-key strategy plus a stored prior session id), compacts the task markdown, and omits the description from its prompt-embedded JSON copy. > This is a focused correctness/efficiency fix to existing wake plumbing and does not overlap with planned roadmap feature work. ## Model Used - Anthropic Claude Fable 5 (`claude-fable-5`), extended thinking enabled, with repository tool use, shell execution, and local test execution via Claude Code. ## 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) - [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details (execution-workspace branch, same convention as merged #10202) - [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 (code-level docs; no user-facing docs affected) - [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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>canary/v2026.724.0-canary.15 |
||
|
DottaandPaperclip
|
d3c004d1b8 |
Fix issue descriptions in structured wake payloads (#10151)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Heartbeat wake payloads provide the scoped task context an agent needs before it can act safely > - Assignment wakes already loaded the issue description for task markdown, but the structured wake-payload builder dropped it > - Agents reading `PAPERCLIP_WAKE_PAYLOAD_JSON` could therefore see a missing brief while also being told no fallback fetch was needed > - Long descriptions also need a bounded representation so wake environments and prompts remain safe > - This pull request carries the description through the server and adapter contract, and marks truncated descriptions as requiring fallback fetch > - The benefit is that agents receive the actual brief instead of inventing requirements from the title ## Linked Issues or Issue Description Fixes: #5844 Fixes: #2882 Related prior attempts: #2883 and #8402. This change adds focused regression coverage and enforces the missing long-description fallback invariant. **Bug:** Issue-assignment wake payloads omitted the issue description from the structured payload even when the issue had a populated description. **Expected behavior:** The structured wake payload includes the issue description. If the description must be truncated for payload size, `fallbackFetchNeeded` is `true`. **Reproduction:** Assign an issue with a description to an agent and inspect `PAPERCLIP_WAKE_PAYLOAD_JSON`; before this change, `issue.description` was absent while `fallbackFetchNeeded` could remain `false`. **Affected version:** Reproduced on current `master` before this patch. **Deployment mode:** Adapter-backed heartbeat execution, including local Codex agents. ## What Changed - Include `issues.description` in the server wake-payload query and supplied issue summaries. - Bound inline descriptions at 12,000 characters and force fallback fetch when truncation occurs. - Preserve and render description metadata through shared adapter normalization and prompt rendering. - Add focused tests for long-description fallback and exact brief-string rendering. ## Verification - `pnpm exec vitest run server/src/__tests__/heartbeat-agent-session-message.test.ts packages/adapter-utils/src/server-utils.test.ts` — 81 tests passed. - `pnpm --filter @paperclipai/adapter-utils typecheck` — passed. - `pnpm --filter @paperclipai/server typecheck` — passed. - `git diff --check` — passed. ## Risks - Low risk: the payload shape is additive. - Very long descriptions are truncated at 12,000 characters; the payload explicitly requests a fallback fetch for the full brief. - Prompt size increases by the issue-description length for scoped wakes, bounded by the same limit. > This is a focused correctness fix and does not overlap with planned roadmap feature work. ## Model Used - OpenAI GPT-5.4 via Codex CLI, with reasoning, repository tool use, shell execution, and test execution. The runtime did not expose a context-window size. ## 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>canary/v2026.724.0-canary.14 |
||
|
DottaandPaperclip
|
b3b07ae44e |
fix(codex): preserve silent active builds (#10153)
## Thinking Path > - Paperclip is the open source control plane people use to coordinate AI agents and their work. > - Local adapters are responsible for observing agent subprocesses and terminating runs that are genuinely stuck. > - The Codex local adapter currently treats output bytes as its only liveness signal for the 30-minute inactivity monitor. > - Healthy compile and test loops can consume CPU and perform disk I/O for longer than that without producing terminal output. > - Terminating those runs loses valid work, while removing the monitor entirely would allow truly wedged processes to run indefinitely. > - This pull request adds a Linux process-group activity probe that recognizes meaningful CPU, disk I/O, and child-process churn while retaining the existing timeout for idle processes. > - The benefit is that long silent builds can finish without weakening the adapter's hung-run safety net. ## Linked Issues or Issue Description No public GitHub issue was found in the duplicate/related search. **What happened** A healthy Codex local run executing a long compile/test loop could be terminated at the default 30-minute output-inactivity threshold when the child process emitted no stdout or stderr. **Expected behavior** The inactivity monitor should keep a silent run alive while its process group is doing meaningful work, but should still terminate a process group that is alive and idle. **Steps to reproduce** 1. Run Codex local with the default `outputInactivityTimeoutMs`. 2. Have the agent start a compile or test command that consumes CPU or disk I/O without terminal output for longer than the threshold. 3. Observe the adapter terminate the otherwise healthy process group as output-inactive. **Affected version / deployment mode** Observed on a local-process Paperclip deployment using the Codex local adapter with the 30-minute default inactivity monitor. ## What Changed - Added a Linux `/proc` process-group sampler that tracks meaningful CPU tick growth, disk I/O growth, and child-process membership changes. - Reset the existing Codex inactivity timer when that sampler observes real process work, while leaving remote and non-Linux behavior unchanged. - Added diagnostics for the number of process-activity resets and documented the expanded liveness semantics. - Added unit coverage for process-activity timer resets and subprocess regressions for both a long silent CPU build and a genuinely wedged child. ## Verification - `pnpm --filter @paperclipai/adapter-codex-local typecheck` - `pnpm exec vitest run packages/adapters/codex-local/src/server/process-activity-monitor.test.ts packages/adapters/codex-local/src/server/output-inactivity-monitor.test.ts packages/adapters/codex-local/src/server/output-inactivity-monitor.integration.test.ts` - Focused result: 23 tests passed, including a silent CPU-bound subprocess that runs four times beyond the simulated inactivity window and an idle subprocess that is still terminated. ## Risks - Low risk and Linux-scoped: the new probe reads `/proc` every 15 seconds only while a monitored local Codex child is running. - The CPU threshold requires sustained work rather than any single scheduler tick, reducing the risk that a nearly idle event loop is treated as productive. - If `/proc` sampling is unavailable or fails, the adapter falls back to the existing output-only behavior. > 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 with model `gpt-5.6-sol`, high reasoning effort, terminal/tool execution, code editing, and test execution. The runtime did not expose a context-window size. ## 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>canary/v2026.724.0-canary.13 |
||
|
DottaandPaperclip
|
e4662b1f9d |
fix: preserve control plane access in Codex sandbox (#10152)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI agents for work > - Local coding adapters can be confined with filesystem and network sandbox policies > - Codex confinement proxied only user-allowlisted hosts, so it denied Paperclip's own run API and managed MCP endpoints > - The same proxy returned untyped plaintext denials, which MCP clients could treat as a fatal unexpected content type > - Host-only `PAPERCLIPAI_CMD` values could also leak into agents even when the referenced checkout module did not exist > - This pull request gives the sandbox an explicit trusted-URL channel for Paperclip endpoints, returns structured JSON errors, and removes the inherited host CLI pointer > - The benefit is confined Codex agents retain control-plane access without broadening the operator's external network allowlist or crashing on policy denials ## Linked Issues or Issue Description Refs #3802 Related foundation: #9504 ### What happened? A `codex_local` agent configured with `networkScope: "allowlist"` and an external-only allowlist could not reach its own Paperclip API or Paperclip-managed MCP endpoints. The sandbox proxy returned a `403` plaintext response without `Content-Type`, and an inherited `PAPERCLIPAI_CMD` could point at a missing checkout-local CLI module. ### Expected behavior Paperclip's run-scoped API and managed MCP endpoints remain reachable regardless of the user external allowlist. Policy denials are valid structured JSON responses with an explicit media type, and host-only CLI pointers are not inherited by agent processes. ### Steps to reproduce 1. Configure a `codex_local` agent with `networkScope: "allowlist"` and `networkAllowlist: ["api.openai.com"]`. 2. Run the agent and request its Paperclip issue API or a Paperclip-managed MCP endpoint. 3. Observe the sandbox proxy deny the request with an untyped plaintext `403` response. ### Environment - Paperclip commit: `f49a3f99` originally exhibited the defect; fix is based on current `master`. - Deployment: local source build on Linux. - Adapter: Codex. - Database: not database-related. - Access context: agent bearer/run-scoped credentials. ## What Changed - Added internal trusted URL rules to the local network allowlist proxy and supplied the Codex run API plus managed MCP endpoints. - Returned JSON error envelopes with `Content-Type` and `Content-Length` for HTTP and CONNECT policy denials. - Removed inherited `PAPERCLIPAI_CMD` from child process environments while preserving explicitly constructed runtime variables. - Added focused proxy and environment sanitizer regression tests. ## Verification - `pnpm exec vitest run packages/adapter-utils/src/local-process-sandbox.test.ts packages/adapter-utils/src/server-utils-env.test.ts --reporter=verbose` - 2 test files passed; 8 tests passed; 4 platform-dependent tests skipped. - `git diff --check` - Package typecheck was attempted; it reaches unrelated current-`master` type drift in untouched files (`spawnCwd` in `adapter-utils`, and staged-runtime ACP types in `codex-local`). ## Risks - Low risk: trusted access is restricted to exact HTTP(S) hostname and port pairs derived from Paperclip-provided URLs. - Invalid or non-HTTP trusted URL values are ignored rather than broadening access. - Denial response bodies change from plaintext to structured JSON; status codes remain unchanged. > 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 (exact model ID and context window are not exposed to this runtime), reasoning and terminal/tool execution 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 - [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>canary/v2026.724.0-canary.12 |
||
|
|
762ce5b4ef |
feat(acpx): per-step timing observability for sandbox run-startup (#10204)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Sandbox-backed runs need observable startup behavior so operators can see where time is spent before an adapter is invoked > - The current startup path only surfaced aggregate timing, which makes it hard to identify the slow boundary in the bring-up sequence > - That gap matters because sandbox startup latency is often dominated by one specific step, and aggregate timing hides the bottleneck > - This pull request adds per-step startup timing events for the named sandbox bring-up boundaries > - The benefit is more precise observability with no control-flow change and no schema migration ## Linked Issues or Issue Description ### Subsystem affected Cross-cutting (multiple of the above) ### Problem or motivation Sandbox run startup only exposed aggregate timing. That makes it hard to identify which bring-up boundary is responsible for slow starts, especially in remote or sandboxed execution where the bottleneck can move between workspace setup, skill reconciliation, bridge setup, and adapter handshake. ### Proposed solution Emit a structured timing event for each named startup boundary before the adapter is invoked, so the existing run-event stream carries per-step duration data. This keeps the event path additive and lets operators see which step dominates startup latency without changing control flow or introducing a schema migration. ### Alternatives considered - Keep only the aggregate startup duration: simpler, but it hides the bottleneck and makes regression analysis much harder. - Add a new telemetry sink or schema field: rejected because the existing run-event payload already carries structured event data and does not need a new storage path. - Log unstructured text for each step: rejected because it is harder to query and aggregate than a structured `step` + `durationMs` event. ### Roadmap alignment This fits the roadmap direction around cloud / sandbox agents and enforced outcomes by improving observability for sandboxed execution without changing the control plane model. The roadmap section is broad, but it does not call out this specific startup-timing work as a planned duplicate. ### Additional context This PR is intentionally additive. It records timing for the named startup boundaries in the existing event stream and leaves the bridge, database shape, and adapter invocation order unchanged. ## What Changed - Added a `measureStartupStep` helper that times a startup step, emits one structured `run.startup.step` event, and rethrows failures after recording duration - Wrapped the seven sandbox bring-up boundaries in `execute.ts` so the structured timing covers each named step before adapter invocation - Added unit coverage for the helper and integration coverage for the startup-step events in the adapter-utils execute path - Kept the event path additive, with no bridge change and no database migration ## Verification - `tsc --noEmit` for `@paperclip/adapter-utils` - `pnpm test` in `packages/adapter-utils` equivalent suite coverage: 292 passed, 4 skipped - Adjacent server event/log-store suites: `run-log-store.test.ts` and `heartbeat-run-log.test.ts` passed (11 total) - Git validation: fetched `origin/feat/sandbox-startup-step-timing`, confirmed it matches the authorized submit SHA, and confirmed `origin/master..origin/feat/sandbox-startup-step-timing` contains the expected single commit - Searched GitHub for duplicate or related open PRs/issues and found no overlapping open items - Checked `ROADMAP.md`; the roadmap covers sandboxed environments generally, but does not call out this specific startup-timing observability work as a planned duplicate ## Risks - Low risk: the change is additive and only emits additional structured events - If downstream consumers assume startup events are aggregate-only, they may need to ignore or account for the new `run.startup.step` entries - Timing is measured via the injected clock and event emission happens in a `finally`, so failures still report duration before rethrowing ## Model Used OpenAI GPT-5, tool-using coding agent ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.724.0-canary.11 |
||
|
|
7014e46e5b |
fix(recovery): wake ambiguous successful runs on normal model (#10184)
## Thinking Path > - Paperclip is the open source control plane people use to coordinate AI agents and their work. > - The heartbeat recovery subsystem detects successful runs that leave assigned issues `in_progress` without a durable disposition or continuation path. > - The existing corrective wake used a cheap, status-only model profile, so the assignee could not perform missing verification or deliverable work before choosing the issue disposition. > - The existing wake prompt also omitted the original issue context and the agent's own final report, making an honest finish/blocked/continue decision harder. > - This pull request keeps the structural handoff guards and one-attempt loop bound, but wakes the assignee on its normal model lane with context-rich instructions. > - The benefit is that Paperclip asks the responsible agent to inspect its own evidence, perform the smallest missing verification when needed, and then record a real disposition without server-side prose classification. ## Linked Issues or Issue Description Related prior approach: #10154 (closed; this PR intentionally does not reuse its regex classifier or route-level gate). **Problem** A succeeded agent run can leave its issue `in_progress` with no valid disposition. Paperclip already detects this structurally and queues a corrective handoff, but that wake currently runs as cheap/status-only recovery and receives little context. The assignee may be unable to create deliverables or verify the work, and the prompt does not quote the report that caused the ambiguity. **Expected behavior** The corrective wake should use the assignee's normal model and adapter settings, include the issue identifier/title/description, quote the agent's own final report, include any recorded next action, preserve the four disposition options, and explicitly require concrete verification before marking the issue done. **Scope** This change does not classify run prose, add a route-level disposition gate, alter run-liveness classification, or change the one-attempt handoff loop bound. ## What Changed - Switched successful-run corrective handoff payloads and context snapshots from `status_only` to `normal_model`, removing cheap-model and status-only guard hints. - Added issue description, final-report, next-action, and detected-progress fallback context to the handoff decision and instruction builder. - Reworked the instruction into clear "supposed to do / what happened / options / what to do" sections with bounded description/report excerpts and verbatim blockquotes. - Added unit and heartbeat integration coverage for normal-lane payloads, context plumbing, evidence quoting, fallback behavior, and truncation while preserving structural skip tests. ## Verification - `cd server && pnpm exec vitest run src/services/recovery/successful-run-handoff.test.ts` — 24 tests passed. - `cd server && pnpm exec vitest run src/__tests__/heartbeat-process-recovery.test.ts -t "queues one finish-handoff wake when a successful run leaves in-progress work without a next action"` — 1 passed, 90 skipped. - `pnpm --dir server typecheck` — passed. - `git diff --check` — passed. ## Risks - Low-to-moderate behavioral risk: an ambiguous successful run now consumes the assignee's normal model rather than a cheap profile and may perform verification or finish work before disposition. - Prompt excerpts are bounded to approximately 1,200 description characters and 2,000 report characters; very long context is intentionally ellipsized. - The existing structural skip guards, idempotency key, and single corrective attempt remain unchanged to prevent loops. > 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 using `gpt-5.6-sol`, high reasoning effort, with repository/tool execution. Context-window size was not exposed by the runtime configuration. ## 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> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>canary/v2026.724.0-canary.10 |
||
|
|
c9881223e4 |
fix(routines): show routines grouped by folder name (#10201)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Routines page is part of the operator UI for scheduled routine management > - The grouped-by-folder view was not presenting folder sections inline in the main pane > - That made the folder grouping mode harder to scan and hid the separation between custom folders, Unfiled routines, and built-in routines > - This pull request updates the Routines page rendering so folder groups appear as inline sections and built-in routines still split into their own section afterward > - The benefit is that grouped routines stay readable and the page matches the intended folder organization ## Linked Issues or Issue Description No corresponding public GitHub issue exists, so the problem is described directly below following the bug template. ### What happened On the Routines page, selecting Group → Folder flattened the grouped list into a single "All routines" section with only the separate built-in routines section below it. ### Expected behavior Group → Folder should render one inline section per folder, keep routines with no folder in an Unfiled section, and preserve the separate built-in routines section after the custom folder groups. ### Steps to reproduce 1. Open the Routines page. 2. Change grouping to Folder. 3. Observe the main pane. 4. The routine list is flattened instead of grouped into folder-labeled inline sections. ### Paperclip version / commit Current PR head: `a8e384c838e362de3437c7a88bc7aa38b10fd9c0` on `fix/routine-folder-grouping`. ### Deployment mode Local development workspace for the Paperclip app UI. ## What Changed - Updated the Routines page rendering so grouped folders render as inline sections instead of flattening into a single list. - Kept routines without a folder grouped under Unfiled. - Preserved the built-in routines section after custom folder groups. - Added and updated tests for the folder-grouped rendering behavior. ## Verification - `pnpm --filter @paperclipai/ui exec vitest run src/pages/Routines.test.tsx` - `pnpm --filter @paperclipai/ui typecheck` - `pnpm check:token-gates` ## Risks - Low risk: the change is localized to the Routines page rendering and its test coverage. - The main behavioral risk is accidental grouping regressions if future routine-grouping logic changes without updating the tests. ## Model Used OpenAI Codex, GPT-5, tool-use enabled, 256k-context class model. ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Harold Kim <harold@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>canary/v2026.724.0-canary.9 |
||
|
DottaandClaude Fable 5
|
3a16b91217 |
feat(status-cards): single-message setup drives query and update prompt (#10202)
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies and their ongoing work. > - Status cards turn a standing question into recurring, agent-generated summaries on the board. > - The existing setup split intent across a watch prompt and separate update instructions, which made creation and later behavior harder to understand. > - A status card should have one durable source of truth for both deciding what to watch and telling the summarizer what each update must contain. > - This pull request makes the card prompt that source of truth, simplifies creation to one step, and lets operators choose the running agent immediately. > - The benefit is a smaller mental model, fewer configuration modes, and consistent update instructions throughout the card lifecycle. ## Linked Issues or Issue Description Status cards currently require operators to express the same intent in two places: the watch prompt and optional update instructions with append/replace/none modes. This feature simplifies the experimental status-card workflow so a single prompt defines both the watch query and every generated update. The create flow must also support selecting the responsible agent without a second setup step. Related prior status-card work: #10101. ## What Changed - Use the status card's single prompt to compile the watch query and directly instruct every summary update. - Add migration `0190_status_card_single_prompt` to remove `status_cards.instructions_mode` and `status_cards.instructions`. - Add `agentId` to `createStatusCardSchema`, validate company membership, and default new cards to the built-in Summarizer. - Replace the two-step create flow with one prompt-and-agent dialog and extract a shared `SummarizerAgentSelect` for create/settings surfaces. - Remove the extra-instructions settings section, reset incremental history when the prompt changes, and rename the board page to "Status". - Update the bundled `status-card-query` skill and board-operator documentation, then regenerate the skills catalog manifest. ## Verification - Server status-card suites: 29/29 passing. - UI `StatusCards` suites: 22/22 passing. - Skills catalog suite: 20/20 passing. - `tsc -b` passes for server, UI, shared, and database packages. - `pnpm check:migrations` passes. - Light and dark mode screenshots cover the new create dialog and settings tab. ## Risks - Migration `0190` intentionally drops existing separate instruction text. Existing card prompts remain and become the update instructions under the new model; status cards are experimental and feature-flagged. - Prompt edits now reset the incremental summary chain and trigger a full rebuild, which is intentional because the prompt is also the update contract. - Agent selection is company-scoped; invalid agent ids return a validation error rather than creating a misrouted card. > 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 - Implementation: Anthropic Claude via the `claude_local` adapter, agent label "Claude Fable 5"; extended reasoning, tool use, and code execution. The exact provider model id and context-window value were not retained in the task metadata. - PR preparation: OpenAI GPT-5.4 through Codex CLI, with reasoning, repository inspection, GitHub CLI, and Paperclip API tool use. ## 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) - [ ] 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: Claude Fable 5 <noreply@anthropic.com>canary/v2026.724.0-canary.8 |
