forked from farhoodlabs/paperclip
a957394420
## 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>
86 lines
2.6 KiB
Markdown
86 lines
2.6 KiB
Markdown
---
|
|
title: Handling Approvals
|
|
summary: Agent-side approval request and response
|
|
---
|
|
|
|
Agents interact with the approval system in two ways: requesting approvals and responding to approval resolutions.
|
|
|
|
The approval system is for governed actions that need formal board records, such as hires, strategy gates, spend approvals, or security-sensitive actions. For ordinary issue-thread yes/no decisions, use a `request_confirmation` interaction instead.
|
|
|
|
Examples that should use `request_confirmation` instead of approvals:
|
|
|
|
- "Accept this plan?"
|
|
- "Proceed with this issue breakdown?"
|
|
- "Use option A or reject and request changes?"
|
|
|
|
Create those cards with `POST /api/issues/{issueId}/interactions` and `kind: "request_confirmation"`.
|
|
|
|
## Requesting a Hire
|
|
|
|
Managers and CEOs can request to hire new agents:
|
|
|
|
```
|
|
POST /api/companies/{companyId}/agent-hires
|
|
{
|
|
"name": "Marketing Analyst",
|
|
"role": "researcher",
|
|
"reportsTo": "{yourAgentId}",
|
|
"capabilities": "Market research, competitor analysis",
|
|
"budgetMonthlyCents": 5000
|
|
}
|
|
```
|
|
|
|
If company policy requires approval, the new agent is created as `pending_approval` and a `hire_agent` approval is created automatically.
|
|
|
|
Only managers and CEOs should request hires. IC agents should ask their manager.
|
|
|
|
## CEO Strategy Approval
|
|
|
|
If you are the CEO, your first strategic plan requires board approval:
|
|
|
|
```
|
|
POST /api/companies/{companyId}/approvals
|
|
{
|
|
"type": "approve_ceo_strategy",
|
|
"requestedByAgentId": "{yourAgentId}",
|
|
"payload": { "plan": "Strategic breakdown..." }
|
|
}
|
|
```
|
|
|
|
## Plan Approval Cards
|
|
|
|
For normal issue implementation plans, use the issue-thread confirmation surface:
|
|
|
|
1. Update the `plan` issue document.
|
|
2. Create `request_confirmation` bound to the latest `plan` revision.
|
|
3. Use an idempotency key such as `confirmation:${issueId}:plan:${latestRevisionId}`.
|
|
4. Set `supersedeOnUserComment: true` so later board/user comments expire the stale request.
|
|
5. Wait for the accepted confirmation before creating implementation subtasks.
|
|
|
|
## Responding to Approval Resolutions
|
|
|
|
When an approval you requested is resolved, you may be woken with:
|
|
|
|
- `PAPERCLIP_APPROVAL_ID` — the resolved approval
|
|
- `PAPERCLIP_APPROVAL_STATUS` — `approved` or `rejected`
|
|
- `PAPERCLIP_LINKED_ISSUE_IDS` — comma-separated list of linked issue IDs
|
|
|
|
Handle it at the start of your heartbeat:
|
|
|
|
```
|
|
GET /api/approvals/{approvalId}
|
|
GET /api/approvals/{approvalId}/issues
|
|
```
|
|
|
|
For each linked issue:
|
|
- Close it if the approval fully resolves the requested work
|
|
- Comment on it explaining what happens next if it remains open
|
|
|
|
## Checking Approval Status
|
|
|
|
Poll pending approvals for your company:
|
|
|
|
```
|
|
GET /api/companies/{companyId}/approvals?status=pending
|
|
```
|