## Thinking Path
> - Paperclip uses pull request CI to check changes before merge.
> - The merged CI profiler records a selected full PR suite in
Honeycomb.
> - A real 48-job profile exposed an export failure after Honeycomb
accepted only part of the trace.
> - The same run exposed three fixture subprocesses that looked like
incomplete test launches, one direct reporter without a launcher marker,
and one overlong test name.
> - The exporter needs to handle temporary ingest rejection without
sending accepted spans again.
> - This pull request fixes those cases and documents the trace display
limit.
> - The benefit is a complete, checkable CI waterfall with test-file
timings.
## Linked Issues or Issue Description
**What happened?**
The first live `profile-ci` run on #16423 completed all 48 jobs, but the
post-run exporter stopped when Honeycomb rejected part of a batch. The
initial trace had no root span. Its coverage flag also reported four
unfinished invocations and one invalid timing record.
**Expected behavior**
The exporter should pace large uploads, retry only temporarily rejected
events, and publish the root after every child is accepted. Completed
reporters should count as complete. Long test names should not erase
test timing.
**Steps to reproduce**
1. Add `profile-ci` to a CI CODEOWNER PR with the merged profiler.
2. Run the full PR suite, as in [run
38732093469](https://github.com/paperclipai/paperclip/actions/runs/38732093469).
3. Inspect the separate [failed exporter
run](https://github.com/paperclipai/paperclip/actions/runs/38733393370)
and the trace coverage fields.
**Paperclip version or commit**
`12612b06eb4332844ac4c8770a1fb6c6b7eccbc9` (PR run head, based on merged
#16378).
## What Changed
- Pace Honeycomb uploads and retry only transiently rejected events from
each batch.
- Preserve overlong test timings with bounded names and count complete
reporter pairs without a launcher record.
- Keep nested Vitest fixture runs from inheriting CI profiling and
creating false coverage gaps.
- Clarify ordinary CI access, large-trace display limits, and export
behavior in the operator guide.
## Verification
- [Full PR
suite](https://github.com/paperclipai/paperclip/actions/runs/38732093469/attempts/1):
48 of 48 jobs succeeded; 10m 29s wall time. The selected jobs used the
AWS public PR fleet. The protected exporter used a separate
GitHub-hosted runner.
- [Clean Honeycomb file
waterfall](https://ui.honeycomb.io/paperclip/environments/test/datasets/paperclip-ci/trace?trace_id=01ed0c541b0442e613a030ffb6dc8d9b&trace_start_ts=1792065955&trace_end_ts=1792066584):
48 jobs, 822 steps, 2,622 file spans, and `ci.profile_complete=true`. It
was reconstructed from that run's 45 timing artifacts after identifying
three nested fixture records. The full trace also recorded 44,497 tests;
Honeycomb's chart omits some deep test spans because it displays at most
32,000 spans per trace.
- The original exporter stopped after a partially accepted batch. A
local replay of that batch succeeded. I used the authorized local
test-environment key to complete the original upload and create the
file-level view. No key was added to this branch or PR.
- `node --test .github/scripts/tests/ci-profile.test.mjs
scripts/ci-profile/reporters.test.mjs`: 18 passed.
- `pnpm exec vitest run
server/src/__tests__/vitest-chat-shards.test.ts`: 1 passed.
- `git diff --check`: passed.
- The local `pnpm -r typecheck` and profiled fixture rerun could not
start: the package-manager shim could not verify the `pnpm@9.15.4`
registry signature because its fetches failed. `pnpm test:run` and `pnpm
build` were not run locally; hosted CI is pending.
- The updated exporter has not yet run from protected `master`; this PR
remains draft until CI and review finish.
## Risks
- A 48,000-span export now takes about three extra minutes due to
pacing. Retry limits still fail a persistently rejected batch and keep
the root unpublished.
- Honeycomb may retain duplicates from an already partial export. The
clean file-level evidence trace uses a separate trace ID.
- The API key stays only in the protected `ci-profiling` environment. PR
jobs write timing artifacts but never receive it.
> 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 — see
`CONTRIBUTING.md`.
## Model Used
OpenAI Codex, GPT-6 family, with reasoning, code execution, GitHub API,
and browser inspection. The runtime does not expose the exact serving
model ID or 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
- [ ] 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>
Batch retained-reader project checks through the existing multi-actor read API. Share raw database reads within one call, retain actor-specific privacy and supplied membership data, and avoid loading large saved-run payloads for identity checks.
Keep current-reader writes, distinct saved-run policies, company root fences and later-call revocation checks. Add query-count and access-control regressions. All 255 affected cases and full repository typecheck/build pass. Hosted response-time acceptance remains separate.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
## Thinking Path
> - Paperclip lets people manage AI agents and their work.
> - Grok Bot can request governed work from its own conversation.
> - Managed Runner admission can take longer than the initial MCP
response.
> - The dispatcher treated a delayed offer as a reason to start another
routine.
> - The original conversation was already waiting for that same work.
> - This pull request keeps admission in its original request and
cancels old prepared echoes.
> - Users get one task interaction while normal assigned-task wakes
remain available.
## Linked Issues or Issue Description
Refs #16219 and #16394. The duplicate search found no other proactive
Grok correction.
**What happened?**
A real idle Grok conversation created one Paperclip task and reached
accepted completion. During admission, the dispatcher also sent a
routine webhook after the offer was ten seconds old. Two acceptance
requests and two title writes were recorded. The extra routine can
compete with the original conversation.
**Expected behavior**
Immediate and delayed Bot-initiated admission stay with the original
request. The Bot checks the same request ID and arguments until
admission succeeds or fails. A new routine must not echo that work back
to the Bot.
**Steps to reproduce**
1. Ask an idle Grok Bot to create and complete a Paperclip task.
2. Let managed admission return pending.
3. Leave its offered assignment unaccepted for more than ten seconds.
4. Run the dispatcher. It sends another routine webhook for that
proactive offer.
**Paperclip version or commit**
Observed through the actual Grok client on Core
11d69d04c7. Both new wake regressions also
fail on current master before this correction.
## What Changed
- Remove the delayed proactive-admission wake scan.
- Fence prepared proactive wakes using the current binding and
generation. A dispatcher restart cancels those old intents without
sending them.
- Tell Grok to keep checking its original queued request. Preserve Dot
event instructions and normal assigned-task dispatch.
- Add delayed-offer and recovered-intent regressions. Update the agent
guide and release evidence plan.
## Verification
- Two new network regressions fail before the fix. The corrected Grok
and Dot suites pass all 80 checks.
- The full focused Grok, Dot, MCP authorization/shutdown and
question-delivery selection passes 214 checks across six files.
- Repository typecheck and build pass. Token gates, the 2,731-story
structural catalog and Storybook build pass. All these checks also pass
after the branch was rebased onto master
250429942e.
- The real-client investigation created one task and one managed run,
saved a 100-word report, reached canonical Done and recorded successful
lease cleanup. Its exact public source marker was absent from the
operator prompt, and no Paperclip proxy operation fetched it. The
no-echo condition failed on that source; this PR still requires a
deployed real-client repeat.
- Public synthetic marker for the deployed repeat:
`grok-native-read-8731cd8120b140829fbe476f6974fde8`.
- Current-head CI passes with 55 successful checks and two optional
Storybook skips. Greptile reviewed
e6b828af28 at 5/5 with no findings.
- The first workspace CI attempt hit a 5,000ms timeout in the unchanged
snapshot-worker command-preparation test. All four variants passed
locally; one targeted remote retry passed. The initial failure is
retained and its root cause is not established.
## Risks
Grok must keep checking the original request while admission is pending.
If that conversation ends, the durable request remains available for
reconciliation; Paperclip cannot infer provider idleness from a delay.
Prepared intents from older dispatchers are cancelled by the authority
guard. The real client must verify the polling path after deployment. No
schema migration is needed.
## Model Used
OpenAI GPT-6 in Codex, with reasoning, repository editing, shell tools
and computer use. The exact serving model ID, snapshot and context
window are not exposed by this 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>
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Its PR workflow runs dozens of parallel build and test jobs.
> - Individual job durations do not show the elapsed cost of the whole
suite.
> - Maintainers need one shared timeline to find slow work and repeated
setup.
> - This pull request adds full-suite profiles for selected CI CODEOWNER
PRs.
> - Honeycomb shows each job, step, test file, and supported test on
that timeline.
> - The benefit is evidence for changes that reduce total CI time.
## Linked Issues or Issue Description
**What existing behavior does this improve?**
The main PR workflow has about 48 jobs. Maintainers need to compare
their overlapping work and find which jobs delay completion.
**Current behavior**
GitHub shows job and step durations separately. Test files and tests are
not joined to a full workflow trace.
**Proposed behavior**
A CI CODEOWNER adds `profile-ci` to a PR. The tested code stays on that
PR branch. All main PR lanes run, including lanes normally skipped for
stack position or release notes. A trusted post-run exporter sends one
wall-clock trace to Honeycomb.
**Reason and benefit**
The trace supports decisions about which CI work to speed up or remove.
Ordinary PRs do not export traces. The roadmap and related-PR search
found no duplicate CI profiling work.
## What Changed
- Add label selection and a full-suite override. Verify the PR author,
original actor, and rerun actors against the trusted `.github/**`
CODEOWNERS rule.
- Record Vitest, Playwright, and Node test file/test timings in local
artifacts. Keep ordinary reporter behavior and failing exit codes.
- Add a trusted `workflow_run` exporter. Use actual GitHub timestamps
for all jobs, setup, steps, waiting, and teardown. Mark missing test
data and partial reruns.
- Keep the ingest key out of PR jobs. Store it only in the
`ci-profiling` environment, restricted to `master`. The exporter reads
bounded JSON and never executes artifact code.
- Record expected test invocations outside reporters so a missing
invocation cannot appear complete. Preserve `node --test` on older PR
checkouts. Flush large shard inventories before exit.
- Add security, timing, routing, and real-reporter checks. Document
operation and activation. Protect the exporter with CODEOWNERS.
## Verification
- 509 focused workflow/reporter/shard checks passed. They include
outside authors, outside rerun actors, bots, stale revisions, malicious
ZIP paths, incomplete reports, and partial ingestion failures.
- Final revision `3bf5d9017d` adds multi-file qualification and fixes
short-file step parenting and duplicate Node file-wrapper events.
Greptile reviewed this exact revision at 5/5 with no unresolved threads.
[Main PR CI
run](https://github.com/paperclipai/paperclip/actions/runs/38728040302):
the initial attempt had 54 successful checks, 3 intentional skips, and
one serialized-shard failure from an unchanged workspace-authorization
test exceeding its 15-second timeout. The single failed-shard retry
passed: the final result is 55 successful checks and 3 intentional
skips. The same timeout reproduces locally with profiling disabled; both
assertions pass with a diagnostic 60-second timeout override (about 23
seconds total). No source or CI timeout was changed.
- A dry run against real GitHub attempt 2 of run `38677445871` produced
exactly 3 executed jobs, 40 spans, and 510 seconds, excluding 45
carried-over jobs. The partial trace remains explicitly incomplete; this
validation did not upload data.
- `actionlint` passed for all four changed workflows. `git diff --check`
passed.
- Full Node 24 `pnpm -r typecheck` and `pnpm build` passed. The local
full `pnpm test:run` was stopped after it reported a setup-token timeout
and a distribution-plugin-catalog fixture failure. The 30 setup-token
tests passed on focused rerun. The plugin fixture fails at `rmSync` of a
directory symlink on this macOS/Node 24.11.0 host; the same failure
reproduces with the unchanged base Vitest configuration and unchanged
test/service files (10 other tests pass). The local full test suite is
therefore not claimed green.
- A real root-config Vitest probe passed 13 tests with profiling both
off and on. Multi-file Vitest, Playwright, and Node probes each verify
two distinct filename rows and four correctly parented tests, including
repeated test names across files. Separate passing probes exercise the
full exporter hierarchy `workflow → job → step → filename → tests`.
Intentional failing probes preserve failing exit status.
- Verified all 48 measured jobs in latest-head run `38728040302` used
AWS: one `paperclip-ci-routing-x64` gate and 47
`paperclip-public-pr-x64` jobs. Profiling preserves AWS authorization
and its GitHub-hosted fallback. The separate privileged exporter runs on
`ubuntu-latest` outside the measured suite.
- [Live Honeycomb
baseline](https://ui.honeycomb.io/paperclip/environments/test/datasets/paperclip-ci/trace/oaPMzw8zGwG):
48 jobs, 731 spans, 479 seconds. It matches [GitHub run
38671274294](https://github.com/paperclipai/paperclip/actions/runs/38671274294).
This historical trace has job/step data only; it is not proof of the
future label-triggered test-reporting journey.
- Verified the dedicated Honeycomb key is ingest-only with dataset
creation disabled. Verified the GitHub environment allows only the
`master` branch. No repository-level secret of that name exists. Both
credential values were scanned absent from source and branch history.
After merge, add `profile-ci` to a CI CODEOWNER PR, wait for the entire
PR run and exporter, then follow the run-summary link. Collapse job
children to compare parallel lanes; expand a job to inspect its steps
and tests.
## Risks
- Activation requires merging the trusted workflow definitions to
`master`. This PR continues using the current trusted reusable workflows
until then.
- Selected runs produce many spans and artifacts. Oversized artifacts
fail export instead of truncating data. Missing or cancelled reporters
are marked incomplete.
- GitHub timings have second precision. Node test times use reporter
receipt time. Rust retains job/step timing but lacks per-test wall
timestamps.
- CI CODEOWNERS are individual users in the explicit `.github/**` rule.
Unsupported team rules and identity lookup failures disable profiling.
- An interrupted upload can leave partial data. Retrying uses the same
span IDs, but the Events API does not promise deduplication.
## Model Used
OpenAI Codex, GPT-6 family, with reasoning, code execution, repository
tools, and browser verification. The runtime does not expose the exact
serving model ID or 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
- [ ] 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>
Move native sandbox snapshot captures off the controller callback queue while preserving the existing capture and restore contract. Keep legacy adapters inline, bound captures to two workers, and verify cleanup and reordered worker completion.
Validation: 461 affected cases, full typecheck/build, exact-head CI/E2E/Superagent and Apex 5/5. The full local canonical suite remains running; no full local pass or under-30-second staging response is claimed.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Classify typed Codex ACP `service` failures about model capacity or server overload as `codex_transient_upstream` / `transient_upstream`, so the existing bounded transient retry and continuation recovery apply. In `unexpected` Sentry mode, skip only runs carrying that full classified evidence; `all` mode still reports them.
Restart reattachment can fail in the executor before the native coordinator saves its result. The run failure report now reads the closed remote recovery stage and reason from the caught error when the saved result lacks them. The saved result keeps priority and the same closed-vocabulary validation applies.
Add a regression for thrown, wrapped-transport, saved-priority, and out-of-vocabulary cases. Full current-head CI and Greptile 5/5 passed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep stored system notices visible without letting them occupy the final reply slot. Read presentation metadata in live and recovery selection, and cover explicit replies, progress receipts, company boundaries, and native replay.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Preserve deliberate assignee blocks and operator stops during dependency and run-release recovery. Attribute native waits to their bound owner. Ignore unrelated edits and shared-workspace exports from another issue. Continue after genuine dependency changes while preserving independently authorized user input.
Keep the original contributor's implementation and review history. Add native ownership, unrelated-edit, later readiness, and shared-workspace regressions. The shared-workspace loop was reproduced before the fix.
Co-Authored-By: Devin Foley <devin@paperclip.ing>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Replay this preparation’s verified private workspace seed after failed warm validation, including when the generation cache refuses publication. Preserve host-current semantics and rebuild if the private seed is missing or changed.
Verified 89 focused cases, full typecheck/build, exact-head CI/E2E/security and Apex 5/5. Live PAP latency acceptance remains separate.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Preserve the verified company/workspace seed-cache scope when a warm sandbox requires host-current staging. Keep remote identity checks, archive digests and rebuilding for missing or corrupt cache generations.
85 focused cases and full repository typecheck/build pass. Exact-head full CI/E2E, Superagent, legacy Snyk and Apex 5/5 pass with no unresolved findings. No staging response-time claim is made.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native agents can edit files in a remote sandbox before they submit
a result.
> - A process identity or startup failure can end the run before file
export.
> - Cleanup can then delete the sandbox and its unpublished files.
> - This pull request retains the exact source and records a file repair
action before cleanup.
> - Operators can recover the files without replaying the failed turn or
changing the task owner.
## Linked Issues or Issue Description
**What happened?**
A native remote process had completed local edits when process identity
recovery failed. The run still had a prepared workspace reference and no
accepted result. Cleanup deleted the source sandbox. No file recovery
card appeared. A restarted run can hit the same path during setup,
before the native executor starts.
**Expected behavior**
Retain the exact unexported source. Show the existing file recovery
card. Require source stop and file recovery evidence. Keep task
ownership, status, and external action reconciliation separate from file
repair.
**Steps to reproduce**
1. Run a native agent in a remote ephemeral workspace and make
unpublished edits.
2. Fail process identity recovery before result acceptance or file
export.
3. Allow failure handling and lease cleanup to run.
4. Before this change, cleanup can destroy the source without a file
repair action.
Refs: #16341 for related process identity diagnostics. Refs: #16349 for
startup ownership fencing. This change addresses file retention after
failure.
## What Changed
- Record source retention and a file recovery action in the terminal
native failure transaction.
- Cover restarted preparation failures before the terminal setup writer
and cleanup run.
- Require the exact company, run, lease, provider allocation, and
workspace binding. Require the exact live recovery claim to settle an
owned preparation failure. Refuse stale or competing claims.
- Reuse the existing stop-only cleanup and file-only reconciliation
path. Leave accepted results and scheduled same-run recovery on their
existing paths.
- Document the retention rule and add database and runtime boundary
regressions.
## Verification
- All 1,242 tests passed across the full heartbeat recovery suite,
native executor, native source retention, runtime teardown, run
completion, and legacy file recovery.
- The integrated missing-descriptor regression fails before the
inner-handler fix and passes after it. The runtime retention and owned
restart regressions also reproduce their prior failures.
- The tests cover exact source identity, current and stale claims,
atomic rollback, cancellation, idempotence, and file-only repair on a
completed task.
- `pnpm -r typecheck` passed on the final code.
- `pnpm build` passed on the final code.
- Full repository CI passed on
`3945eb2ba5c228c5d4992da02b765dcf2e634cb8`: 54 successful checks and two
skipped Storybook checks.
- Apex scored 5/5 on that exact commit. Both earlier findings are fixed
and all review threads are resolved.
- The unsharded local `pnpm test:run` is still in progress. It is not
counted as a local full-suite pass; complete suite coverage is verified
in CI.
## Risks
- Failed runs can retain a sandbox that needs operator cleanup after
file recovery. This uses the existing retention policy and recovery
controls.
- This does not recover files from allocations that were already
deleted.
- No schema migration, UI change, or telemetry change is required.
## Model Used
- OpenAI GPT-6 through Codex. Tool use, code execution, and reasoning
assisted this change. The environment identifies the model as GPT-6; it
does not expose a more specific serving snapshot or 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>
## Thinking Path
> - Paperclip lets people manage AI agents and their work.
> - Grok Bot receives assignments through routine webhooks and uses
agent MCP tools.
> - Each accepted assignment belongs to the current external
interaction.
> - A pending tool result or comment could start another routine while
that work was still active.
> - Quiet MCP traffic cannot prove that Grok has stopped working.
> - This pull request keeps receipts and feedback durable for the
current interaction to read.
> - New task routines start only for offers that the Bot has not
accepted.
## Linked Issues or Issue Description
Refs #16219 and #16305. The duplicate search also found #12991, which
covers instruction files for local Grok runs.
**What happened?**
The dispatcher could start another routine for an unread result after a
period without a routine reply. It could also wake accepted work for a
task comment. A queued delivery could still start after the Bot had
claimed the offer.
**Expected behavior**
Accepted work stays in its current interaction. The Bot polls the
original operation receipt and reads queued feedback at a safe boundary.
Acknowledgements of a sent wake remain valid after acceptance.
**Steps to reproduce**
1. Accept a Grok assignment and leave it active.
2. Add an unread comment, or complete a tool operation whose call
returned pending.
3. Run the dispatcher after its quiet period.
4. Observe another webhook call. Also queue an offer wake, accept the
offer before sending, and observe that delivery still starts.
**Paperclip version or commit**
Observed during real-client qualification on Core
ff0f976de1. The three new regression cases
also failed on current master before the correction.
## What Changed
- Stop automatic result and feedback wakes for accepted work. Keep both
available through their existing read paths.
- Require an unaccepted offer before dispatch or an explicit delivery
retry. Serialize the final HTTP handoff with acceptance receipts. Cancel
obsolete unsent wakes. Preserve late acknowledgements and immediate Stop
authority.
- Return current Grok polling instructions on assignment reads. Clarify
pending and unknown outcomes in setup guidance.
- Add protocol, receipt-polling, queued-delivery and
late-acknowledgement regressions. Update the operation guide and
readiness plan.
## Verification
- Three new regression cases fail before the fix because a webhook
starts.
- The latest 31 Grok protocol checks and 47 existing Dot Runner checks
pass. New tests force acceptance during secret lookup and the final send
check. They also prove that acknowledgements and Stop remain free during
pending delivery.
- The final-head Grok, Dot, MCP and question-delivery suite passes all
212 checks across six files. Dedicated onboarding UI checks passed six.
- Dedicated Runner driver checks use the real local Rust daemon. Built
the debug daemon required by that package; all 17 checks then passed.
- Repository typecheck and build pass. Token gates, the 2,731-story
structural catalog and the Storybook build pass.
- Public synthetic marker for the post-deployment native source-read
check: `grok-native-read-b45be4eff22cb15a31d0af512f437b8d`.
- Final-head CI passes all 55 checks, with two optional Storybook skips.
Greptile is 5/5 with no open threads. The first chat-shard attempt
failed one Telegram SQL-quiet timing assertion; all five related cases
pass locally and the single targeted CI rerun passes.
- After deployment, repeat actual Grok work through an answered
question, receipt polling, a saved report and file, canonical completion
and cleanup. This correction is not production qualification by itself.
## Risks
A Bot that does not poll a pending receipt can wait without another
routine wake. Current assignment reads now supply polling instructions
to existing connections. Task comments stay queued until the Bot reads
them or Runner admits the next continuation. The real client must verify
that behavior before production enablement. The observed second file
version does not prove which provider interaction created it. Acceptance
can wait for the bounded webhook response. Stop and authenticated
acknowledgements use independent row locks and remain available.
## Model Used
OpenAI GPT-6 in Codex, with reasoning, repository editing, shell tools
and browser tools. The exact serving model ID, snapshot and context
window are not exposed by this 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>
Batch retained workspace admission reads while preserving individual privacy and trust decisions. Preserve bounded saved-policy projections when integrating current master, and qualify the pinned Claude executable on Linux ARM64.
Verified exact head 4d468f998b with full CI/E2E, Superagent, Snyk and Apex 5/5, with no unresolved findings. Local typecheck/build and 209 server plus 74 integrity cases pass; full local suite remains pending.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
