mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-14 00:26:28 +01:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agents read runtime prompts, tool help, skills, and role instructions. > - Several of these texts tell agents to create child tasks as a normal next step. > - One accepted-plan prompt even forbids work on the current task. > - Task parentage is useful, but it does not need a prompt that encourages task creation. > - This pull request removes those prompts and keeps the task APIs available. ## Linked Issues or Issue Description Refs #10642. This change adjusts prompt wording; it does not add delegation-cycle guards. **Current behavior** Prompts tell agents to create children after plan approval, use children for long work, and create a task just to pass context. Onboarding requires a child even for a single request. **Proposed behavior** Continue work on the current task. Keep explicit assignments, optional task creation, parentage, dependencies, and approval gates. Use the separate-task recipes when the user requests that structure or when continuing existing work. **Reason and benefit** Reduce needless task trees without removing subtask support. Keep the patch limited to wording, existing test expectations, and generated catalog data. ## What Changed - Align accepted-plan prompts and remove direct child-creation advice from runtime and error text. - Make task tool descriptions neutral. Keep their fields, defaults, and handlers. - Update the main skill, onboarding, CEO instructions, company templates, specialist workflows, and matching guides. - Keep historical release snapshots intact. Refresh the explicitly seeded schema fixture's catalog digest; the server still verifies historical release snapshot hashes. - Refresh the affected generated catalogs, capability inventory, semantic contracts, and fixture manifest. ## Verification - Final tested head: `c6e304d0c105cdbfbe0b2ab0a233307fcd91a04b`. - All 66 check runs are complete: 60 pass, one is neutral, and five are skipped by CI conditions. Snyk also passes. No checks fail or remain pending. - [PR CI](https://github.com/paperclipai/paperclip/actions/runs/42846226554) passes typecheck, build, server/general tests, all eight E2E shards, Runner support, Runner Rust, and the aggregate verify gate. [Windows](https://github.com/paperclipai/paperclip/actions/runs/42846226546) and [Docker Runner](https://github.com/paperclipai/paperclip/actions/runs/42846226108) also pass. - [Greptile](https://github.com/paperclipai/paperclip/pull/20362#issuecomment-6751419835) and [Paperclip review](https://github.com/paperclipai/paperclip/pull/20362#issuecomment-6751454010) give this exact head 5/5. All six inline threads are resolved. Neither current summary has findings. - Merged master `bf0220d34a156c81853755c3d1365ddc527037de`. Resolved three generated-file conflicts with the canonical generators. - Local verification passes: 473 focused prompt, continuation, UI, catalog, runtime and native-execution tests; Runner TypeScript build; generated metadata; UI token gates; and diff checks. - The prior head `c22018cb0f` failed three SDK evidence tests because two source hashes were stale. Reproduced all three failures locally. The existing generator refreshed only the hashes for the denial-copy file and its test. All 53 affected evidence/source-pin tests then passed, including private-value rejection. No scanner logic, assertions, or runtime dependency pins changed. Current CI confirms the support suite passes. - A prior commit failed the Rust process reaping test. Its cause remains unproven. No Rust code or assertions changed. Later Rust runs pass; this does not establish the cause of the earlier failure. - Local preflight built shared/plugin SDK packages, then stopped because `cargo` is absent. Current-head CI supplies Rust and full build coverage. `pnpm verify --explain` selects broad required CI; full local suites were not repeated. ## Risks - Wording changes guide the model; they do not enforce a ban on subtasks. - Existing installed skill versions and saved custom instructions need their normal refresh process. This PR does not migrate company configuration. - Existing approved task assignments and approval gates remain in effect. ## Model Used - OpenAI GPT-6, through Codex, with reasoning, tool use, and code execution. The exact routed model ID and context-window size were not exposed in 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>
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 implementation.
|
|
|
|
## 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
|
|
```
|