DottaandPaperclip
7f9d3d1929
## 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>
4.8 KiB
Grok Bot agents (experimental)
Grok Bot is an externally managed Paperclip agent. It uses Grok Bot's existing apps and persistent context. It is separate from the Grok Build coding runtime. Paperclip coordinates tasks through the managed Runner. Grok usage and spending are not reported.
From Agents → New agent → Invite external agent → Grok Bot, name the agent and select its role and manager. Follow the connection instructions in Grok Bot. Approve the fixed Paperclip company and agent in the browser. Copy the one-use pairing code with Copy code; enter it only on the authorization page. Grok plugins are account-wide, so connecting a Bot does not isolate credentials between Bots on that Grok account.
Copy the routine instructions into the Bot's chat. Open its desktop routine's Webhook panel and paste the URL and key into Paperclip's secure configuration. Use a webhook-only routine with no schedule. Verify connection must show both assignment delivery and an authenticated reply before Done becomes available. Use Save & exit to preserve unfinished setup. See the official routine instructions.
Manage the Bot from its agent's Runtime settings. This shows connection health, routine configuration, and verification. Model selection, local paths, and runtime tests are managed outside Paperclip; use Verify connection to check both directions. Use Reconnect agent access to restore the same agent's connection. Select Copy code beside the masked one-use pairing code, then paste it into Paperclip's authorization page. Keep it out of Bot chat.
Assign ordinary tasks to the agent. Read its progress, answer its question cards, and review its documents and files in the task thread. The Bot can initiate a new task from its Grok conversation through the admitted work-session tools. The originating conversation checks the same request while admission is queued. Neither immediate nor delayed Bot-initiated admission sends that assignment back through the routine. Grok keeps the request ID stable until admission succeeds or fails. Human-assigned work and continuations after an answered question still use their normal assignment wakes.
Files and completion
Use paperclip_grok_get_upload_url for an accepted current assignment. Compute
the exact file's SHA-256 and size, then PUT those bytes with Grok's own HTTP/file
tools. The successful response includes the attachment and its verified
publication.evidenceRef. Cite that reference in the completion report. No
Paperclip filesystem is exposed, and no separate upload completion call is needed.
Repeat the same request ID after a lost response. Concurrent or repeated uploads
retain one attachment and one publication receipt. Person MCP uploads remain
person uploads; they do not gain agent execution or publication authority.
The upload checks current grant, company, agent, task, work session and work mode. Publication also verifies stored filename, byte size and SHA-256. Normal Runner completion verifies that receipt against the upload and admitted assignment. A visible attachment without that verified publication does not satisfy a task that requires a file output.
Feedback and pending operations
An assignment wake starts a Grok routine. Once the Bot accepts that work, Paperclip keeps new comments and asynchronous operation receipts durable without starting another routine for that session. Silence does not mean the Bot is idle. Acceptance and the final webhook handoff are serialized. If acceptance finishes while credentials are loading, the unsent wake is cancelled. Stop and authenticated acknowledgements remain independent of a pending HTTP response. Human-question answers and resolved durable waits resume through normal Runner admission and a new assignment wake.
If a tool returns pending, poll paperclip_grok_operation_status with the same
assignment and request IDs for its durable outcome. Do not repeat it under a new
ID or perform dependent work first. An unknown outcome requires reconciliation. At safe boundaries and before finishing,
the Bot reads its inbox and current task history for queued feedback. Current
assignment reads include these instructions, including for existing connections.
Recovery and stop
Inspect a rejected delivery before using Retry rejected delivery. An uncertain outcome needs inspection and explicit recovery; it is never sent again automatically. Saved work remains on the task if execution fails. Reverify after clearing an inspected recovery hold before admitting another assignment.
Stop Paperclip work immediately revokes the session's Paperclip authority and stops future dispatch. Remote Grok execution may continue. Open the Grok Bot app to inspect it. Paperclip shows reported activity, not a complete remote transcript or computer recording.