mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-20 15:09:57 +02:00
## 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 Core11d69d04c7. 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 master250429942e. - 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 reviewede6b828af28at 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>