Keep updated task objectives across later resumes while preserving new human direction and explicit interactions.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Give the complete recovery test time for its deliberate fault, resumed turn timeout, and durable filesystem writes. Keep all per-turn deadlines and correctness assertions unchanged.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Keep unchanged skill preferences intact and normalize the empty connector digest. Accept exact prior default-shaped session hashes without exempting real configuration changes. Exercise actual connector preparation for legacy and native session compatibility.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Register resource cleanup immediately so early fixture errors cannot leak the temporary PostgreSQL cluster or clients.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Apply the exact published preview migration history to an empty PostgreSQL database before upgrading. Preserve task and provider identities, file and trash references, pending sync operations, repository checkpoints, and the original journal. Compare all work-folder tables with a fresh database and verify idempotent replay.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Paperclip Cloud deploys images that contain the native Rust Runner.
> - The image already builds that Runner before copying ordinary app
source.
> - A Rust source change still invalidates its entire compiled
dependency layer.
> - Compiled dependencies can survive source changes when their recipe
is unchanged.
> - This PR adds a separate locked dependency build before compiling the
real workspace.
## Linked Issues or Issue Description
Refs #13195. A search of related Docker and Cargo cache PRs found no
duplicate dependency-recipe change.
**What existing behavior does this improve?**
Docker image build time after Rust source or embedded protocol changes.
**Current behavior**
The `runner-build` stage compiles dependencies and workspace code in one
layer. In Cloud readiness run 34698143548, that stage took about 3m48s
when its cache was unavailable.
**Proposed behavior**
Generate a recipe with pinned cargo-chef 0.1.73. Build locked release
dependencies in `runner-deps`, then copy and compile real Rust source
and embedded protocol inputs in `runner-build`. Source edits can reuse
the dependency layer from the existing registry cache.
**Reason and benefit**
Reduce dependency recompilation during source changes and merge bursts.
Expected savings are roughly 2–4 minutes when the old native layer would
miss but dependency layers are available. Full cold builds also pay for
the recipe tool installation. Ordinary app-only cache hits gain little
from this change.
**Breaking changes**
None to the shipped application or image tags. The recipe tool and
compiled dependencies remain in build stages.
## What Changed
- Install a pinned recipe generator with its locked dependencies and the
existing package-owned compiler.
- Add recipe planning and compiled dependency stages. Use the same
release profile, package, binary, and lockfile enforcement as the real
native build.
- Remove generated source stubs before copying actual source. Preserve
protocol inputs, timestamp normalization, binary staging, and
application checks.
- Add Docker cache wiring regressions and update the Docker cache
documentation.
- Run a two-build probe in Docker Runner check. It requires dependency
reuse, changed real binary metadata after a source edit, and a changed
recipe after a dependency declaration edit. It uses a disposable
tracked-source context and exports only small metadata files.
## Verification
- Passed all five Docker build-stamp and dependency-cache tests with
`pnpm exec vitest run server/src/__tests__/docker-build-stamp.test.ts`.
- Passed the local ARM64 `docker buildx build --target runner-build
--progress plain`. Local Docker then hit storage errors during a runtime
probe; cache invalidation verification continues on GitHub-hosted Linux.
- Passed `bash -n scripts/check-docker-runner-cache.sh`, `actionlint`,
and `git diff --check`.
- Passed a [Linux AMD64 cache
probe](https://github.com/paperclipai/paperclip/actions/runs/34711042199)
against the PR source: dependencies compiled in 3m49s for the baseline
and were `CACHED` after a source edit; real source compilation took
about 37 seconds. Binary metadata changed and dependency declaration
changes altered the recipe. The permanent probe is also running in
latest-head Docker Runner check.
- Passed latest-head [Docker Runner
check](https://github.com/paperclipai/paperclip/actions/runs/34711145160),
including the permanent source/dependency invalidation probe.
- Passed full [PR
verification](https://github.com/paperclipai/paperclip/actions/runs/34711145352/attempts/2):
typecheck, all grouped tests, native verification, build, release dry
run, and browser checks. One unrelated signoff-policy browser test
failed waiting for a heartbeat run on attempt 1; only that failed shard
and dependent checks were retried, and passed.
- Latest-head Greptile is 5/5 with no unresolved findings. Full local
tests/build were limited by local disk exhaustion; Linux CI completed
those checks.
## Risks
- The two-build CI probe has a 20-minute job limit to cover the cold
build and source rebuild. It adds no AWS routing.
- A fully cold build must install cargo-chef and populate the dependency
layer. Both become reusable registry layers; no Actions cache is added.
- The recipe and final build must keep the same compiler, build profile,
package, binary, and directory layout. A source-change rebuild probe
checks real cache reuse and binary invalidation.
- Dependency or compiler changes still require rebuilding dependencies.
Existing image verification and full-SHA publication gates remain
unchanged.
## Model Used
OpenAI GPT-6 through Codex, with reasoning, repository tools, and code
execution. The exact serving model ID and context window are not exposed
by this environment.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have 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>
Exercise actual heartbeat teardown around both native selection cancellation boundaries with controlled sandbox and checkpoint failures. Verify retention, unsaved-copy survival, no release, and saved-message admission only after checkpoint recovery and scoped termination proof.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Preserve operator-stop recovery suppression when newer callers release a run using only its company and run IDs.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* codex/work-folders-storybook-refresh:
Move preview-upgrade regression coverage to the final acceptance layer
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* codex/work-folders-runtime-hardening-refresh:
Move preview-upgrade regression coverage to the final acceptance layer
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* codex/work-folders-pi-refresh:
Move preview-upgrade regression coverage to the final acceptance layer
Co-Authored-By: Paperclip <noreply@paperclip.ing>
* codex/work-folders-base-refresh:
Move preview-upgrade regression coverage to the final acceptance layer
Keep the base PR below the repository file-count gate; the final session-compatibility layer retains this integration coverage.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Cloud deployments wait for verified source commits.
> - Verification splits serialized server tests across independent
runners.
> - The shard duration estimates came from August and no longer match
current tests.
> - Stale estimates put much more work on one runner than the others.
> - This PR refreshes the estimates from a complete successful run to
balance the existing runners.
## Linked Issues or Issue Description
**What existing behavior does this improve?**
The time spent waiting for the slowest serialized server-test shard in
PR and release verification.
**Current behavior**
In [Cloud readiness run
34705914878](https://github.com/paperclipai/paperclip/actions/runs/34705914878),
the five serialized shards spent 479, 371, 322, 390, and 365 seconds
running tests. The recovery suite had a 55-second estimate but now takes
about 156 seconds including process overhead.
**Proposed behavior**
Use fresh per-suite measurements with the existing deterministic
duration balancer. Applying the same measured costs to the new
assignment gives 385, 385, 386, 385, and 385 seconds. This predicts
about 93 seconds less waiting for the slowest shard, before runner/setup
overhead. Live CI will confirm the result.
**Reason and benefit**
Use the existing runners more evenly. No extra runner, test parallelism,
cache, timeout, or routing change is needed.
**Breaking changes**
Suite-to-shard assignments change. The full suite set, assertions, and
per-suite process isolation stay the same.
**Additional context**
Searched related CI and shard PRs. This updates the existing duration
manifest, without duplicating a pending sharding implementation.
## What Changed
- Refresh all 145 serialized suite weights from the same successful
release verification run.
- Record source job IDs and the measurement method in the manifest.
Durations include process startup, imports, collection, tests, and
shutdown.
## Verification
- Passed all 30 shard and release-workflow tests: `node --test
scripts/__tests__/run-vitest-stable-shard.test.mjs
scripts/__tests__/release-verify-workflow.test.mjs`.
- Confirmed every measured suite appears exactly once across all five
source logs.
- Compared old and new assignments using the same measured weights. The
maximum fell from 478862ms to 385551ms.
- In [PR CI run
34710696242](https://github.com/paperclipai/paperclip/actions/runs/34710696242),
all five serialized jobs passed in 7m05s–7m27s including setup. The
measured assignment is now balanced in a live run.
- The same run passed full typecheck, all grouped tests, native
verification, build, release dry run, and browser checks. Local
full-suite verification on this base was limited by disk exhaustion;
local typecheck and targeted shard tests passed.
- Latest-head Greptile is 5/5 with no open findings. Every current-head
CI check must be green or intentionally skipped before merge.
## Risks
- Individual durations vary with load and future test changes. These
estimates affect assignment only; missing or renamed suites receive the
existing median weight.
- Both PR and release verification read this manifest, so both receive
the new assignments. Each suite still runs in its own serialized Vitest
process.
## Model Used
OpenAI GPT-6 through Codex, with reasoning, repository tools, and code
execution. The exact serving model ID and context window are not exposed
by this environment.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have 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>
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Paperclip Cloud deploys verified images from merged source commits.
> - Cloud readiness waits for every release verification check.
> - Runner verification currently runs long TypeScript tests before Rust
checks.
> - These checks can run on independent runners with their own build
directories.
> - This PR runs them in parallel while preserving all checks and the
shared dependency cache.
## Linked Issues or Issue Description
Refs #13194. Related prior work: #13142 and #13259. A search found no
duplicate parallel release-check change.
**What existing behavior does this improve?**
Time from merge to Cloud source verification and deployment readiness.
**Current behavior**
Recent successful runs take roughly 13 minutes from merge to deployable.
In run 34705914878, Runner verification took 11m23s. Protocol tests
finished before Rust tests and API authority checks started.
**Proposed behavior**
Run protocol and Rust verification in two matrix jobs. Cloud readiness
still requires both jobs to pass.
**Reason and benefit**
Remove the serial dependency between independent checks. Expected
improvement is about 2–3 minutes on a typical cached run, until the
image build or server tests become the longest job. This is an estimate;
post-merge timing will confirm it.
**Breaking changes**
Individual release Runner job names gain a lane suffix. Cloud source and
readiness marker names stay the same. PR runner routing is unchanged.
## What Changed
- Split release Runner checks into protocol and Rust lanes. Keep every
constituent of `check:all` exactly once.
- Restore the existing Rust dependency cache in both lanes. Allow only
the Rust lane to save it after warming both build profiles.
- Add coverage and cache authorization regressions. Document the
parallel verification and single cache writer.
## Verification
- Passed 477 workflow and source-verification tests with `node --test
.github/scripts/tests/*.test.mjs
scripts/cloud-source-verification.test.mjs
scripts/__tests__/release-verify-workflow.test.mjs`.
- Passed `actionlint`, `git diff --check`, and the private AWS routing
regression suite.
- Passed local `pnpm -r typecheck` and the standalone `check:runner &&
check:api-authority` lane, including all 1,671 API tests before the
protocol lane had built TypeScript output.
- The broad local protocol run under Node 25 had four failures. The two
affected files passed under CI's Node 24.19.0: 67 passed, 6 platform
skips.
- Local `pnpm test:run` aborted when disk space ran out; local `pnpm
build` could not run afterward. These are local verification limits.
[Linux CI run
34710421424](https://github.com/paperclipai/paperclip/actions/runs/34710421424)
passed full typecheck, all grouped tests, native verification, build,
release dry run, and browser checks. Native protocol CI passed 1,986
tests, plus 1,671 API tests and the Rust suites.
- Latest-head Greptile is 5/5 with no open findings. All 33 current-head
checks are successful or intentionally skipped.
## Risks
- Uses one additional short-lived verification runner per release
verification. The existing AWS exact-master restriction remains in
place.
- The Rust lane warms debug dependencies so its cache save also serves
protocol tests. Both lanes always rebuild workspace code.
- A workflow regression could omit a check. The new coverage test
compares the matrix checks directly with `check:all`; Cloud readiness
depends on the complete reusable workflow.
## Model Used
OpenAI GPT-6 through Codex, with reasoning, repository tools, and code
execution. The exact serving model ID and context window are not exposed
by this environment.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have 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>
Recheck pending approvals and questions when cleanup already cleared the recovery action, and distinguish final admission rejection from a non-applicable continuation. Add deterministic cross-connection admission coverage for held and resolved recovery, receipt preservation, and exactly-once resumption.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
