Files
paperclip/docs/api/issues.md
Dotta a957394420 [codex] Add structured issue-thread interactions (#4244)
## 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>
2026-04-21 20:15:11 -05:00

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 key plan, when present
  • documentSummaries: metadata for all linked issue documents
  • legacyPlanDocument: 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 reject
  • ask_user_questions: ask structured questions and store selected answers
  • request_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 baseRevisionId when creating a new document
  • provide the current baseRevisionId when updating an existing document
  • stale baseRevisionId returns 409 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_progress requires checkout (single assignee)
  • started_at auto-set on in_progress
  • completed_at auto-set on done
  • Terminal states: done, cancelled