Apply the reviewed single-route compatibility fix for the case564 representative journey. Preserve the original catalog, model, inputs and time limits.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Mirror the reviewed source fixture setup barrier before the unchanged composer assertion. Preserve all catalog protocol and production inputs.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Use one ownership projection for window-independent history presence and recorded events. Preserve ordered narrative facts across punctuation.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Exercise the real task PATCH producer before timeline reads, and bind narrative attribution directly to the reassignment action.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Calibrate complete narrative attribution without first-match wording, and retain independent command, audit, privacy and link checks.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native remote sessions keep their controller state in a database
checkpoint.
> - An admission can also leave a full local copy of a prior run's
state.
> - The prior owner can commit more state without changing its run ID.
> - Warm admission skipped a refresh when the local and saved run IDs
matched.
> - This pull request refreshes that prior-run copy when no retained
warm owner exists.
> - The next turn can use the committed state while existing ownership
checks remain effective.
**What happened?**
A prior warm run can complete after an earlier admission reads its
controller checkpoint. The local copy can still contain a pending
command or lack the final terminal event. A later admission sees the
same run ID and skips restoration. It can then hold work against that
old copy even though the database checkpoint has settled.
**Expected behavior**
Read the canonical prior-run checkpoint before reuse when no retained
in-memory owner exists. Keep current-run state with its controller. Keep
unresolved canonical work and invalid checkpoint bindings blocked.
**Steps to reproduce**
1. Create a full prior-run local projection while a command is pending.
2. Complete that command and record the terminal in the canonical
checkpoint under the same run ID.
3. Start an ordinary remote warm continuation without a retained
in-memory owner.
4. Before this change, the local command remains pending. With this
change, the completed command and terminal replace the stale copy.
**Paperclip version or commit**
Reproduced on master `36df8933f0` before changing production code.
Related work: #18018 restored per-turn checkpoints; #18343 added
controller replacement recovery; #18554 restored missing remote
suspension receipts. This change handles a full prior-run projection
whose run ID already matches the saved supervisor. It does not change
the settlement guard or MCP compatibility policy.
- Refresh a prior-run warm controller projection even when its run ID
has not changed.
- Keep current-run and retained warm owner authority on the existing
path.
- Add five executor cases for a settled source, a pending canonical
command, a current run, legacy file-backed state, and an invalid
checkpoint binding.
- Add an opt-in Linux continuity case with a stale full local projection
and two follow-up turns.
- Update execution documentation and the paired session verification
recipes.
- RED before the production edit: the executor fixture retained
`pending` in its local command record when the canonical record was
`completed`.
- GREEN on the final commit: 48 focused tests passed across executor
restoration, retained warm owner rotation, per-turn restoration, and
remote settlement guards.
- `pnpm --filter @paperclipai/server typecheck` passed. The server
TypeScript check also passed after the integration fixture was added.
- `node scripts/check-maps.mjs` and `git diff --check` passed.
- The unit fixture uses the real durable controller serializer and the
real executor entry. It stops at current tool authority before
provider/backend creation. It proves restoration and guard behavior, not
full task acceptance.
- Actual protocol RED/GREEN: the same opt-in continuity fixture uses
real PostgreSQL, TLS, the current Linux Rust Runner, and a deterministic
fake Codex backend. With only the executor restored to its parent
revision, continuation fails with
`prior_owner_terminal_state_indeterminate` in the settlement guard after
one provider turn (20.16 seconds). The PR source completes all three
turns with one provider thread and final suspension (34.77 seconds).
Hard recovery permits one provider-process replacement; the healthy
final follow-up starts no additional process. Both runs use the same
Runner binary and owned container.
- The exact PR executor source was restored after the baseline
comparison, its Git blob was verified, and the worktree is clean. The
disposable local container was removed. This fixture proves the
controlled stale-projection recovery path; it does not establish a live
model or Daytona API result.
- Full current-head CI passes, including typecheck, build, general and
serialized tests, Rust/Runner checks, all eight E2E shards, and the `ci
/ e2e` and `ci / verify` aggregate gates. Greptile is 5/5 on the current
commit, with no unresolved review threads. No original task was retried
and no staging sandbox lifecycle was changed.
- Admission without a retained owner performs one additional scoped
checkpoint read when a full prior-run projection already exists.
- The canonical checkpoint must still pass its company, task, session
and record validation. A pending canonical command stays held.
Current-run and retained owner state are not replaced.
- The regression proves a stale local projection defect. It does not
establish that a historical incident had those same local bytes.
OpenAI Codex, GPT-6 family. The harness does not expose the exact
serving model ID or context-window size. Capabilities: repository
inspection, code generation, tools, and test execution.
- [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
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>
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native tasks save a provider session for later comments and monitor
checks.
> - The goal projection also records the run that owns the session event
sequence.
> - A fresh retry uses a new native session, but the projection accepted
only the old session.
> - The accepted checkpoint then rejected session publication because
the goal source still named the old run.
> - This pull request lets the current task executor advance that source
after a terminal predecessor with no unfinished goal.
> - Later turns can then use the fresh retry's saved session.
Related: #12669, #18343. I searched open and closed PRs for source
epochs and native task-session publication. I found no duplicate repair.
**What happened?**
A successful fresh native retry could retain its predecessor's
task-session pointer. A later comment or monitor selected the old
provider session. The goal source transition required both runs to have
the same native session. The terminal checkpoint then saved a
`suppressed_newer` publication result.
**Expected behavior**
The current task executor can publish its accepted fresh session. A
later turn resumes that session. Delayed events cannot restore the old
source or revive a cleared goal.
**Steps to reproduce**
1. Complete a native turn and retain its task-session row.
2. Admit a fresh session on the same task without deleting the row.
3. Complete that turn, then send an ordinary follow-up.
4. Before this change, the saved pointer can still name the first
session.
**Paperclip version or commit**
Reproduced on source commit `36df8933f0` with a PostgreSQL regression
before the production change.
**Deployment mode**
Source checkout. The affected producer runs for local and remote native
sessions.
- Permit a different native session to advance the goal source only when
its run holds the task execution lock and assignee, and the task is in
progress.
- Keep the terminal predecessor, native runtime, runner identity, absent
or completed goal, source sequence, and conversation reset checks.
- Test accepted session publication, a fresh heartbeat followed by an
ordinary resumed turn, stale events, current-owner loss, and unfinished
or unreadable goals.
- Add an opt-in live Codex file-persistence check. Update execution
documentation and both recovery maps.
- Red: the new PostgreSQL publication regression failed before the
producer change. The saved session, display ID and goal source still
named the predecessor.
- Green: 72 distinct tests passed across the final focused runs of
`runner-goals.test.ts`, `native-task-session-publication.test.ts`,
`native-session-resumption.test.ts`, and
`remote-warm-session-recovery.test.ts`.
- The assembled heartbeat test admits three turns, opens two provider
sessions, resumes the second session once, and stores three results. It
uses a deterministic provider backend.
- `node scripts/check-maps.mjs` and `git diff --check` passed.
- Real local Codex acceptance passed on macOS arm64 with `gpt-6.1-sol`
and explicit warm mode. Three heartbeat turns saved three exact file
lines. The fresh second turn published its new normalized and provider
session IDs. The ordinary third turn retained both IDs. The fixture
closed its warm owners and removed its private credential copy and
workspace. The production code was at `450e15e`; the final test-only
commit selects explicit warm mode and uses the existing owned-home
cleanup helper. The production change is identical in the final head.
- The earlier per-turn fixture preserved all three file steps and
selected the correct normalized session, but provider-thread reuse
failed. `run.attach` reported that the Codex provider had pending
events; the safe fallback used another provider thread. This remains a
separate failure. The first fixture cleanup also failed on immutable
instruction assets. The owned-home helper fixed cleanup, and the second
per-turn attempt exposed the provider identity assertion directly.
- Full current-head CI passes, including typecheck, build, general and
serialized tests, Rust/Runner checks, all eight E2E shards, and the `ci
/ e2e` and `ci / verify` aggregate gates. Greptile is 5/5 on the current
commit, with no unresolved review threads. Broad local workspace checks
were not duplicated; the focused regressions and actual provider
acceptance above were run locally. No merge, deployment, or recovery of
an original task is included.
- Source epoch changes affect saved goal state. The fresh-session path
requires current task authority and refuses unfinished or unreadable
saved goals.
- The change starts no provider work and changes no prior-owner recovery
guard. Unknown external outcomes retain their reconciliation hold.
- A prior session remains held when it lacks the required authority or
state proof.
- Per-turn provider-thread reuse remains an open coverage gap described
above. This change does not alter that attachment guard.
OpenAI Codex, GPT-6 family. The exact model ID and context window are
unavailable in this session. The agent used code inspection, tools, and
executable tests.
- [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
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>
