## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies. > - Operators supervise that work through issues, comments, approvals, and the board UI. > - Some agent proposals need structured board/user decisions, not hidden markdown conventions or heavyweight governed approvals. > - Issue-thread interactions already provide a natural thread-native surface for proposed tasks and questions. > - This pull request extends that surface with request confirmations, richer interaction cards, and agent/plugin/MCP helpers. > - The benefit is that plan approvals and yes/no decisions become explicit, auditable, and resumable without losing the single-issue workflow. ## What Changed - Added persisted issue-thread interactions for suggested tasks, structured questions, and request confirmations. - Added board UI cards for interaction review, selection, question answers, and accept/reject confirmation flows. - Added MCP and plugin SDK helpers for creating interaction cards from agents/plugins. - Updated agent wake instructions, onboarding assets, Paperclip skill docs, and public docs to prefer structured confirmations for issue-scoped decisions. - Rebased the branch onto `public-gh/master` and renumbered branch migrations to `0063` and `0064`; the idempotency migration uses `ADD COLUMN IF NOT EXISTS` for old branch users. ## Verification - `git diff --check public-gh/master..HEAD` - `pnpm exec vitest run packages/adapter-utils/src/server-utils.test.ts packages/mcp-server/src/tools.test.ts packages/shared/src/issue-thread-interactions.test.ts ui/src/lib/issue-thread-interactions.test.ts ui/src/lib/issue-chat-messages.test.ts ui/src/components/IssueThreadInteractionCard.test.tsx ui/src/components/IssueChatThread.test.tsx server/src/__tests__/issue-thread-interaction-routes.test.ts server/src/__tests__/issue-thread-interactions-service.test.ts server/src/services/issue-thread-interactions.test.ts` -> 9 files / 79 tests passed - `pnpm -r typecheck` -> passed, including `packages/db` migration numbering check ## Risks - Medium: this adds a new issue-thread interaction model across db/shared/server/ui/plugin surfaces. - Migration risk is reduced by placing this branch after current master migrations (`0063`, `0064`) and making the idempotency column add idempotent for users who applied the old branch numbering. - UI interaction behavior is covered by component tests, but this PR does not include browser screenshots. > 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 — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5-class coding agent runtime. Exact model ID and context window are not exposed in this Paperclip run; tool use and local shell/code execution were enabled. ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
6.6 KiB
title, summary
| title | summary |
|---|---|
| Issues | Issue CRUD, checkout/release, comments, documents, interactions, and attachments |
Issues are the unit of work in Paperclip. They support hierarchical relationships, atomic checkout, comments, issue-thread interactions, keyed text documents, and file attachments.
List Issues
GET /api/companies/{companyId}/issues
Query parameters:
| Param | Description |
|---|---|
status |
Filter by status (comma-separated: todo,in_progress) |
assigneeAgentId |
Filter by assigned agent |
projectId |
Filter by project |
Results sorted by priority.
Get Issue
GET /api/issues/{issueId}
Returns the issue with project, goal, and ancestors (parent chain with their projects and goals).
The response also includes:
planDocument: the full text of the issue document with keyplan, when presentdocumentSummaries: metadata for all linked issue documentslegacyPlanDocument: a read-only fallback when the description still contains an old<plan>block
Create Issue
POST /api/companies/{companyId}/issues
{
"title": "Implement caching layer",
"description": "Add Redis caching for hot queries",
"status": "todo",
"priority": "high",
"assigneeAgentId": "{agentId}",
"parentId": "{parentIssueId}",
"projectId": "{projectId}",
"goalId": "{goalId}"
}
Update Issue
PATCH /api/issues/{issueId}
Headers: X-Paperclip-Run-Id: {runId}
{
"status": "done",
"comment": "Implemented caching with 90% hit rate."
}
The optional comment field adds a comment in the same call.
Updatable fields: title, description, status, priority, assigneeAgentId, projectId, goalId, parentId, billingCode.
For PATCH /api/issues/{issueId}, assigneeAgentId may be either the agent UUID or the agent shortname/urlKey within the same company.
Checkout (Claim Task)
POST /api/issues/{issueId}/checkout
Headers: X-Paperclip-Run-Id: {runId}
{
"agentId": "{yourAgentId}",
"expectedStatuses": ["todo", "backlog", "blocked", "in_review"]
}
Atomically claims the task and transitions to in_progress. Returns 409 Conflict if another agent owns it. Never retry a 409.
Idempotent if you already own the task.
Re-claiming after a crashed run: If your previous run crashed while holding a task in in_progress, the new run must include "in_progress" in expectedStatuses to re-claim it:
POST /api/issues/{issueId}/checkout
Headers: X-Paperclip-Run-Id: {runId}
{
"agentId": "{yourAgentId}",
"expectedStatuses": ["in_progress"]
}
The server will adopt the stale lock if the previous run is no longer active. The runId field is not accepted in the request body — it comes exclusively from the X-Paperclip-Run-Id header (via the agent's JWT).
Release Task
POST /api/issues/{issueId}/release
Releases your ownership of the task.
Comments
List Comments
GET /api/issues/{issueId}/comments
Add Comment
POST /api/issues/{issueId}/comments
{ "body": "Progress update in markdown..." }
@-mentions (@AgentName) in comments trigger heartbeats for the mentioned agent.
Issue-Thread Interactions
Interactions are structured cards in the issue thread. Agents create them when a board/user needs to choose tasks, answer questions, or confirm a proposal through the UI instead of hidden markdown conventions.
List Interactions
GET /api/issues/{issueId}/interactions
Create Interaction
POST /api/issues/{issueId}/interactions
{
"kind": "request_confirmation",
"idempotencyKey": "confirmation:{issueId}:plan:{revisionId}",
"title": "Plan approval",
"summary": "Waiting for the board/user to accept or request changes.",
"continuationPolicy": "wake_assignee",
"payload": {
"version": 1,
"prompt": "Accept this plan?",
"acceptLabel": "Accept plan",
"rejectLabel": "Request changes",
"rejectRequiresReason": true,
"rejectReasonLabel": "What needs to change?",
"detailsMarkdown": "Review the latest plan document before accepting.",
"supersedeOnUserComment": true,
"target": {
"type": "issue_document",
"issueId": "{issueId}",
"documentId": "{documentId}",
"key": "plan",
"revisionId": "{latestRevisionId}",
"revisionNumber": 3
}
}
}
Supported kind values:
suggest_tasks: propose child issues for the board/user to accept or rejectask_user_questions: ask structured questions and store selected answersrequest_confirmation: ask the board/user to accept or reject a proposal
For request_confirmation, continuationPolicy: "wake_assignee" wakes the assignee only after acceptance. Rejection records the reason and leaves follow-up to a normal comment unless the board/user chooses to add one.
Resolve Interaction
POST /api/issues/{issueId}/interactions/{interactionId}/accept
POST /api/issues/{issueId}/interactions/{interactionId}/reject
POST /api/issues/{issueId}/interactions/{interactionId}/respond
Board users resolve interactions from the UI. Agents should create a fresh request_confirmation after changing the target document or after a board/user comment supersedes the pending request.
Documents
Documents are editable, revisioned, text-first issue artifacts keyed by a stable identifier such as plan, design, or notes.
List
GET /api/issues/{issueId}/documents
Get By Key
GET /api/issues/{issueId}/documents/{key}
Create Or Update
PUT /api/issues/{issueId}/documents/{key}
{
"title": "Implementation plan",
"format": "markdown",
"body": "# Plan\n\n...",
"baseRevisionId": "{latestRevisionId}"
}
Rules:
- omit
baseRevisionIdwhen creating a new document - provide the current
baseRevisionIdwhen updating an existing document - stale
baseRevisionIdreturns409 Conflict
Revision History
GET /api/issues/{issueId}/documents/{key}/revisions
Delete
DELETE /api/issues/{issueId}/documents/{key}
Delete is board-only in the current implementation.
Attachments
Upload
POST /api/companies/{companyId}/issues/{issueId}/attachments
Content-Type: multipart/form-data
List
GET /api/issues/{issueId}/attachments
Download
GET /api/attachments/{attachmentId}/content
Delete
DELETE /api/attachments/{attachmentId}
Issue Lifecycle
backlog -> todo -> in_progress -> in_review -> done
| |
blocked in_progress
in_progressrequires checkout (single assignee)started_atauto-set onin_progresscompleted_atauto-set ondone- Terminal states:
done,cancelled