Files
PaperClipAI/server
DottaandPaperclip 7f9d3d1929 fix(grok): avoid routine wakes for proactive admission (#16422)
## 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>
2026-10-15 07:10:35 -05:00
..