@iamlbccc/tdxd 1.1.0 → 1.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/ONBOARD-PROMPT.md +44 -0
- package/README.md +16 -5
- package/lib/tpl.mjs +14 -50
- package/lib/ui.mjs +49 -95
- package/package.json +3 -1
- package/skills/paperclip/SKILL.md +630 -0
- package/skills/paperclip/references/api-reference.md +1511 -0
- package/skills/paperclip/references/artifacts.md +98 -0
- package/skills/paperclip/references/cases.md +295 -0
- package/skills/paperclip/references/company-skills.md +266 -0
- package/skills/paperclip/references/issue-workspaces.md +80 -0
- package/skills/paperclip/references/routines.md +231 -0
- package/skills/paperclip/references/workflows.md +141 -0
- package/skills/paperclip/scripts/paperclip-upload-artifact.sh +371 -0
- package/skills/paperclip-converting-plans-to-tasks/SKILL.md +60 -0
- package/tdxd-ctl.mjs +360 -71
- package/tdxd.mjs +3 -3
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# Issue Workspace Runtime Controls
|
|
2
|
+
|
|
3
|
+
Use this reference when an issue has an isolated execution workspace and you need to inspect or run that workspace's services, especially for QA/browser verification.
|
|
4
|
+
|
|
5
|
+
## Discover the Workspace
|
|
6
|
+
|
|
7
|
+
Start from the issue, not from memory:
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
curl -sS -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
11
|
+
"$PAPERCLIP_API_URL/api/issues/$PAPERCLIP_TASK_ID/heartbeat-context"
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
Read `currentExecutionWorkspace`:
|
|
15
|
+
|
|
16
|
+
- `id` — execution workspace id for control endpoints
|
|
17
|
+
- `cwd` / `branchName` — local checkout context
|
|
18
|
+
- `status` / `closedAt` — whether the workspace is usable
|
|
19
|
+
- `runtimeServices[]` — current services, including `serviceName`, `status`, `healthStatus`, `url`, `port`, and `runtimeServiceId`
|
|
20
|
+
|
|
21
|
+
If `currentExecutionWorkspace` is `null`, the issue does not currently have a realized execution workspace. For child/follow-up work, create the child with `parentId` or use `inheritExecutionWorkspaceFromIssueId` so Paperclip preserves workspace continuity.
|
|
22
|
+
|
|
23
|
+
## Control Services
|
|
24
|
+
|
|
25
|
+
Prefer Paperclip-managed runtime service controls over manual `pnpm dev &` or ad-hoc background processes. These endpoints keep service state, URLs, logs, and ownership visible to other agents and the board.
|
|
26
|
+
|
|
27
|
+
```sh
|
|
28
|
+
# Start all configured services; waits for configured readiness checks.
|
|
29
|
+
curl -sS -X POST \
|
|
30
|
+
-H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
31
|
+
-H "X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID" \
|
|
32
|
+
-H "Content-Type: application/json" \
|
|
33
|
+
"$PAPERCLIP_API_URL/api/execution-workspaces/<workspace-id>/runtime-services/start" \
|
|
34
|
+
-d '{}'
|
|
35
|
+
|
|
36
|
+
# Restart all configured services.
|
|
37
|
+
curl -sS -X POST \
|
|
38
|
+
-H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
39
|
+
-H "X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID" \
|
|
40
|
+
-H "Content-Type: application/json" \
|
|
41
|
+
"$PAPERCLIP_API_URL/api/execution-workspaces/<workspace-id>/runtime-services/restart" \
|
|
42
|
+
-d '{}'
|
|
43
|
+
|
|
44
|
+
# Stop all running services.
|
|
45
|
+
curl -sS -X POST \
|
|
46
|
+
-H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
47
|
+
-H "X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID" \
|
|
48
|
+
-H "Content-Type: application/json" \
|
|
49
|
+
"$PAPERCLIP_API_URL/api/execution-workspaces/<workspace-id>/runtime-services/stop" \
|
|
50
|
+
-d '{}'
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
To target a configured service, pass one of:
|
|
54
|
+
|
|
55
|
+
```json
|
|
56
|
+
{ "workspaceCommandId": "web" }
|
|
57
|
+
{ "runtimeServiceId": "<runtime-service-id>" }
|
|
58
|
+
{ "serviceIndex": 0 }
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
The response includes an updated `workspace.runtimeServices[]` list and a `workspaceOperation`/`operation` record for logs.
|
|
62
|
+
|
|
63
|
+
## Read the URL
|
|
64
|
+
|
|
65
|
+
After `start` or `restart`, read the service URL from:
|
|
66
|
+
|
|
67
|
+
- response `workspace.runtimeServices[].url`
|
|
68
|
+
- or a fresh `GET /api/issues/:issueId/heartbeat-context` response at `currentExecutionWorkspace.runtimeServices[].url`
|
|
69
|
+
|
|
70
|
+
For QA/browser checks, use the service whose `status` is `running` and whose `healthStatus` is not `unhealthy`. If multiple services are running, prefer the one named `web`, `preview`, or the configured service the issue mentions.
|
|
71
|
+
|
|
72
|
+
## MCP Tools
|
|
73
|
+
|
|
74
|
+
When the Paperclip MCP tools are available, prefer these issue-scoped tools:
|
|
75
|
+
|
|
76
|
+
- `paperclipGetIssueWorkspaceRuntime` — reads `currentExecutionWorkspace` and service URLs for an issue.
|
|
77
|
+
- `paperclipControlIssueWorkspaceServices` — starts, stops, or restarts the current issue workspace services.
|
|
78
|
+
- `paperclipWaitForIssueWorkspaceService` — waits until a selected service is running and returns its URL when exposed.
|
|
79
|
+
|
|
80
|
+
These tools resolve the issue's workspace id for you, so QA agents do not need to know the lower-level execution workspace endpoint first.
|
|
@@ -0,0 +1,231 @@
|
|
|
1
|
+
# Paperclip Routines
|
|
2
|
+
|
|
3
|
+
Routines are recurring tasks. Each time a routine fires it creates an execution issue assigned to the routine's agent — the agent picks it up in the normal heartbeat flow.
|
|
4
|
+
|
|
5
|
+
A routine has:
|
|
6
|
+
- One assigned agent and one project
|
|
7
|
+
- One or more triggers (`schedule`, `webhook`, or `api`)
|
|
8
|
+
- A concurrency policy (what to do when a previous run is still active)
|
|
9
|
+
- A catch-up policy (what to do with missed scheduled runs)
|
|
10
|
+
- An activity gate policy (whether quiet scheduled ticks should be skipped)
|
|
11
|
+
|
|
12
|
+
**Authorization:** Agents can read all routines in their company but can only create or manage routines assigned to themselves. Board operators have full access, including reassignment.
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## Lifecycle
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
active <-> paused
|
|
20
|
+
active -> archived (terminal — cannot be reactivated)
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Paused routines do not fire. Archived routines do not fire and cannot be unarchived.
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Creating a Routine
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
POST /api/companies/{companyId}/routines
|
|
31
|
+
{
|
|
32
|
+
"title": "Weekly CEO briefing",
|
|
33
|
+
"description": "Compile status report and post to Slack",
|
|
34
|
+
"assigneeAgentId": "{agentId}",
|
|
35
|
+
"projectId": "{projectId}",
|
|
36
|
+
"goalId": "{goalId}", // optional
|
|
37
|
+
"parentIssueId": "{issueId}", // optional — parent for run issues
|
|
38
|
+
"priority": "medium",
|
|
39
|
+
"status": "active",
|
|
40
|
+
"concurrencyPolicy": "coalesce_if_active",
|
|
41
|
+
"catchUpPolicy": "skip_missed",
|
|
42
|
+
"activityGatePolicy": "always",
|
|
43
|
+
"activityGateScope": "company"
|
|
44
|
+
}
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
| Field | Required | Notes |
|
|
48
|
+
|-------|----------|-------|
|
|
49
|
+
| `title` | yes | Max 200 chars |
|
|
50
|
+
| `description` | no | Human-readable description of the routine |
|
|
51
|
+
| `assigneeAgentId` | yes | Agents: must be themselves |
|
|
52
|
+
| `projectId` | yes | |
|
|
53
|
+
| `goalId` | no | Inherited by run issues |
|
|
54
|
+
| `parentIssueId` | no | Run issues become children of this issue |
|
|
55
|
+
| `priority` | no | `critical` `high` `medium` (default) `low` |
|
|
56
|
+
| `status` | no | `active` (default) `paused` `archived` |
|
|
57
|
+
| `concurrencyPolicy` | no | See below |
|
|
58
|
+
| `catchUpPolicy` | no | See below |
|
|
59
|
+
| `activityGatePolicy` | no | `always` (default) or `require_external_activity`; see below |
|
|
60
|
+
| `activityGateScope` | no | `company` (default) or `project`; see below |
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## Concurrency Policies
|
|
65
|
+
|
|
66
|
+
Controls what happens when a trigger fires while the previous run issue is still open or active.
|
|
67
|
+
|
|
68
|
+
| Policy | Behaviour |
|
|
69
|
+
|--------|-----------|
|
|
70
|
+
| `coalesce_if_active` **(default)** | New run is marked `coalesced` and linked to the existing active run — no new issue created |
|
|
71
|
+
| `skip_if_active` | New run is marked `skipped` and linked to the existing active run — no new issue created |
|
|
72
|
+
| `always_enqueue` | Always create a new issue regardless of active runs |
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
## Catch-Up Policies
|
|
77
|
+
|
|
78
|
+
Controls what happens with scheduled runs that were missed, for example during server downtime.
|
|
79
|
+
|
|
80
|
+
| Policy | Behaviour |
|
|
81
|
+
|--------|-----------|
|
|
82
|
+
| `skip_missed` **(default)** | Missed runs are dropped |
|
|
83
|
+
| `enqueue_missed_with_cap` | Missed runs are enqueued, capped at 25 |
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Activity-Gated Scheduled Runs
|
|
88
|
+
|
|
89
|
+
`activityGatePolicy` controls whether a **schedule trigger** runs when the system has been quiet. It does not gate manual, API, or webhook runs.
|
|
90
|
+
|
|
91
|
+
| Policy | Behaviour |
|
|
92
|
+
|--------|-----------|
|
|
93
|
+
| `always` **(default)** | Run on every scheduled tick |
|
|
94
|
+
| `require_external_activity` | Run only when qualifying activity occurred after this routine's last dispatched, non-skipped run |
|
|
95
|
+
|
|
96
|
+
`activityGateScope` selects where qualifying activity is checked:
|
|
97
|
+
|
|
98
|
+
| Scope | Behaviour |
|
|
99
|
+
|-------|-----------|
|
|
100
|
+
| `company` **(default)** | Activity anywhere in the routine's company can wake it |
|
|
101
|
+
| `project` | Only activity attributed to the routine's project can wake it |
|
|
102
|
+
|
|
103
|
+
The activity window starts at the `triggeredAt` time of the last dispatched run. A routine that has never dispatched always runs once. Runs skipped for quiet activity do not advance the window, so one later qualifying event still wakes the next scheduled tick.
|
|
104
|
+
|
|
105
|
+
The gate excludes activity generated by the routine's own dispatched run issues, scheduler bookkeeping for that routine, and pure-read actions such as issue read/unread changes and inbox archive/unarchive actions. Work performed by other agents on tasks the routine delegated is external activity and wakes the routine on its next tick.
|
|
106
|
+
|
|
107
|
+
### Example: skip quiet nights
|
|
108
|
+
|
|
109
|
+
This hourly watcher runs after company activity, follows up while delegated work continues, and stops consuming runs once the company settles overnight:
|
|
110
|
+
|
|
111
|
+
```json
|
|
112
|
+
{
|
|
113
|
+
"title": "Hourly work watcher",
|
|
114
|
+
"description": "Review recent work and follow up on delegated tasks",
|
|
115
|
+
"assigneeAgentId": "{agentId}",
|
|
116
|
+
"projectId": "{projectId}",
|
|
117
|
+
"activityGatePolicy": "require_external_activity",
|
|
118
|
+
"activityGateScope": "company"
|
|
119
|
+
}
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Add a schedule trigger with `cronExpression: "0 * * * *"`. The first tick runs. Later ticks run only after qualifying company activity since the last dispatched run; quiet skipped ticks keep the original activity window open.
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## Adding Triggers
|
|
127
|
+
|
|
128
|
+
A routine can have multiple triggers of different kinds.
|
|
129
|
+
|
|
130
|
+
All trigger kinds accept an optional `label` field (max 120 chars), which is useful for distinguishing multiple triggers of the same kind on one routine.
|
|
131
|
+
|
|
132
|
+
```
|
|
133
|
+
POST /api/routines/{routineId}/triggers
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
### Schedule (cron)
|
|
137
|
+
|
|
138
|
+
```json
|
|
139
|
+
{
|
|
140
|
+
"kind": "schedule",
|
|
141
|
+
"cronExpression": "0 9 * * 1",
|
|
142
|
+
"timezone": "Europe/Amsterdam"
|
|
143
|
+
}
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
- `cronExpression`: standard 5-field cron syntax
|
|
147
|
+
- `timezone`: IANA timezone string (for example `UTC` or `America/New_York`)
|
|
148
|
+
- The server computes `nextRunAt` automatically
|
|
149
|
+
|
|
150
|
+
### Webhook
|
|
151
|
+
|
|
152
|
+
```json
|
|
153
|
+
{
|
|
154
|
+
"kind": "webhook",
|
|
155
|
+
"signingMode": "hmac_sha256",
|
|
156
|
+
"replayWindowSec": 300
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
- `signingMode`: `bearer` (default) or `hmac_sha256`
|
|
161
|
+
- `replayWindowSec`: 30-86400 (default 300)
|
|
162
|
+
- Response includes the webhook URL (`publicId`-based) and the signing secret
|
|
163
|
+
- Fire externally: `POST /api/routine-triggers/public/{publicId}/fire`
|
|
164
|
+
- Bearer: `Authorization: Bearer <secret>`
|
|
165
|
+
- HMAC: `X-Paperclip-Signature` + `X-Paperclip-Timestamp` headers
|
|
166
|
+
|
|
167
|
+
### API (manual only)
|
|
168
|
+
|
|
169
|
+
```json
|
|
170
|
+
{
|
|
171
|
+
"kind": "api"
|
|
172
|
+
}
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
No configuration. Fire via the manual run endpoint.
|
|
176
|
+
|
|
177
|
+
---
|
|
178
|
+
|
|
179
|
+
## Updating and Deleting Triggers
|
|
180
|
+
|
|
181
|
+
```
|
|
182
|
+
PATCH /api/routine-triggers/{triggerId}
|
|
183
|
+
{ "enabled": false, "cronExpression": "0 10 * * 1" }
|
|
184
|
+
|
|
185
|
+
DELETE /api/routine-triggers/{triggerId}
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
To rotate a webhook secret (the old secret is immediately invalidated):
|
|
189
|
+
|
|
190
|
+
```
|
|
191
|
+
POST /api/routine-triggers/{triggerId}/rotate-secret
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
---
|
|
195
|
+
|
|
196
|
+
## Manual Run
|
|
197
|
+
|
|
198
|
+
Fires a run immediately, bypassing the schedule. Concurrency policy still applies.
|
|
199
|
+
|
|
200
|
+
```
|
|
201
|
+
POST /api/routines/{routineId}/run
|
|
202
|
+
{
|
|
203
|
+
"source": "manual",
|
|
204
|
+
"triggerId": "{triggerId}", // optional — attributes run to a specific trigger
|
|
205
|
+
"payload": { "context": "..." }, // optional — passed to the run issue
|
|
206
|
+
"idempotencyKey": "unique-key" // optional — prevents duplicate runs
|
|
207
|
+
}
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## Updating a Routine
|
|
213
|
+
|
|
214
|
+
All create fields are updatable. Agents cannot reassign a routine to another agent.
|
|
215
|
+
|
|
216
|
+
```
|
|
217
|
+
PATCH /api/routines/{routineId}
|
|
218
|
+
{ "status": "paused", "title": "New title" }
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
## Reading Routines and Runs
|
|
224
|
+
|
|
225
|
+
```
|
|
226
|
+
GET /api/companies/{companyId}/routines
|
|
227
|
+
GET /api/routines/{routineId}
|
|
228
|
+
GET /api/routines/{routineId}/runs?limit=50
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
Use the generic API endpoint tables in `skills/paperclip/references/api-reference.md` when you need a full cross-domain reference. Use this file when you need routine-specific behaviour, payload shape, or policy details.
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
# Paperclip Workflow Playbooks
|
|
2
|
+
|
|
3
|
+
Reference material for niche workflows that are pointed to from `SKILL.md`. Load only when the task matches.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Project Setup (CEO/Manager)
|
|
8
|
+
|
|
9
|
+
When asked to set up a new project with workspace config (local folder and/or GitHub repo):
|
|
10
|
+
|
|
11
|
+
1. `POST /api/companies/{companyId}/projects` with project fields.
|
|
12
|
+
2. Optionally include `workspace` in that same create call, or call `POST /api/projects/{projectId}/workspaces` right after create.
|
|
13
|
+
|
|
14
|
+
Workspace rules:
|
|
15
|
+
|
|
16
|
+
- Provide at least one of `cwd` (local folder) or `repoUrl` (remote repo).
|
|
17
|
+
- For repo-only setup, omit `cwd` and provide `repoUrl`.
|
|
18
|
+
- Include both `cwd` + `repoUrl` when local and remote references should both be tracked.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## OpenClaw Invite (CEO)
|
|
23
|
+
|
|
24
|
+
Use this when asked to invite a new OpenClaw employee.
|
|
25
|
+
|
|
26
|
+
1. Generate a fresh OpenClaw invite prompt:
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
POST /api/companies/{companyId}/openclaw/invite-prompt
|
|
30
|
+
{ "agentMessage": "optional onboarding note for OpenClaw" }
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Access control:
|
|
34
|
+
|
|
35
|
+
- Board users with invite permission can call it.
|
|
36
|
+
- Agent callers: only the company CEO agent can call it.
|
|
37
|
+
|
|
38
|
+
2. Build the copy-ready OpenClaw prompt for the board:
|
|
39
|
+
|
|
40
|
+
- Use `onboardingTextUrl` from the response.
|
|
41
|
+
- Ask the board to paste that prompt into OpenClaw.
|
|
42
|
+
- If the issue includes an OpenClaw URL (for example `ws://127.0.0.1:18789`), include that URL in your comment so the board/OpenClaw uses it in `agentDefaultsPayload.url`.
|
|
43
|
+
|
|
44
|
+
3. Post the prompt in the issue comment so the human can paste it into OpenClaw.
|
|
45
|
+
|
|
46
|
+
4. After OpenClaw submits the join request, monitor approvals and continue onboarding (approval + API key claim + skill install).
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Setting Agent Instructions Path
|
|
51
|
+
|
|
52
|
+
Use the dedicated route instead of generic `PATCH /api/agents/:id` when you need to set an agent's instructions markdown path (for example `AGENTS.md`).
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
PATCH /api/agents/{agentId}/instructions-path
|
|
56
|
+
{
|
|
57
|
+
"path": "agents/cmo/AGENTS.md"
|
|
58
|
+
}
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
Rules:
|
|
62
|
+
|
|
63
|
+
- Allowed for: the target agent itself, or an ancestor manager in that agent's reporting chain.
|
|
64
|
+
- For `codex_local` and `claude_local`, default config key is `instructionsFilePath`.
|
|
65
|
+
- Relative paths are resolved against the target agent's `adapterConfig.cwd`; absolute paths are accepted as-is.
|
|
66
|
+
- To clear the path, send `{ "path": null }`.
|
|
67
|
+
- For adapters with a different key, provide it explicitly:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
PATCH /api/agents/{agentId}/instructions-path
|
|
71
|
+
{
|
|
72
|
+
"path": "/absolute/path/to/AGENTS.md",
|
|
73
|
+
"adapterConfigKey": "yourAdapterSpecificPathField"
|
|
74
|
+
}
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
---
|
|
78
|
+
|
|
79
|
+
## Company Import / Export
|
|
80
|
+
|
|
81
|
+
Use the company-scoped routes when a CEO agent needs to inspect or move package content.
|
|
82
|
+
|
|
83
|
+
- CEO-safe imports:
|
|
84
|
+
- `POST /api/companies/{companyId}/imports/preview`
|
|
85
|
+
- `POST /api/companies/{companyId}/imports/apply`
|
|
86
|
+
- Allowed callers: board users and the CEO agent of that same company.
|
|
87
|
+
- Safe import rules:
|
|
88
|
+
- existing-company imports are non-destructive
|
|
89
|
+
- `replace` is rejected
|
|
90
|
+
- collisions resolve with `rename` or `skip`
|
|
91
|
+
- issues are always created as new issues
|
|
92
|
+
- CEO agents may use the safe routes with `target.mode = "new_company"` to create a new company directly. Paperclip copies active user memberships from the source company so the new company is not orphaned.
|
|
93
|
+
|
|
94
|
+
For export, preview first and keep tasks explicit:
|
|
95
|
+
|
|
96
|
+
- `POST /api/companies/{companyId}/exports/preview`
|
|
97
|
+
- `POST /api/companies/{companyId}/exports`
|
|
98
|
+
- Export preview defaults to `issues: false`
|
|
99
|
+
- Add `issues` or `projectIssues` only when you intentionally need task files
|
|
100
|
+
- Use `selectedFiles` to narrow the final package to specific agents, skills, projects, or tasks after you inspect the preview inventory
|
|
101
|
+
|
|
102
|
+
See `api-reference.md` for full schema examples.
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## Self-Test Playbook (App-Level)
|
|
107
|
+
|
|
108
|
+
Use this when validating Paperclip itself (assignment flow, checkouts, run visibility, and status transitions).
|
|
109
|
+
|
|
110
|
+
1. Create a throwaway issue assigned to a known local agent (`claudecoder` or `codexcoder`):
|
|
111
|
+
|
|
112
|
+
```bash
|
|
113
|
+
npx paperclipai issue create \
|
|
114
|
+
--company-id "$PAPERCLIP_COMPANY_ID" \
|
|
115
|
+
--title "Self-test: assignment/watch flow" \
|
|
116
|
+
--description "Temporary validation issue" \
|
|
117
|
+
--status todo \
|
|
118
|
+
--assignee-agent-id "$PAPERCLIP_AGENT_ID"
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
2. Trigger and watch a heartbeat for that assignee:
|
|
122
|
+
|
|
123
|
+
```bash
|
|
124
|
+
npx paperclipai heartbeat run --agent-id "$PAPERCLIP_AGENT_ID"
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
3. Verify the issue transitions (`todo -> in_progress -> done` or `blocked`) and that comments are posted:
|
|
128
|
+
|
|
129
|
+
```bash
|
|
130
|
+
npx paperclipai issue get <issue-id-or-identifier>
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
4. Reassignment test (optional): move the same issue between `claudecoder` and `codexcoder` and confirm wake/run behavior:
|
|
134
|
+
|
|
135
|
+
```bash
|
|
136
|
+
npx paperclipai issue update <issue-id> --assignee-agent-id <other-agent-id> --status todo
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
5. Cleanup: mark temporary issues done/cancelled with a clear note.
|
|
140
|
+
|
|
141
|
+
If you use direct `curl` during these tests, include `X-Paperclip-Run-Id` on all mutating issue requests whenever running inside a heartbeat.
|