@code-partner/codepipe 0.4.1-dev.128.gd6a3022 → 0.4.1-dev.130.g417592b
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/README.md +42 -283
- package/dist/index.js +112 -112
- package/package.json +2 -1
package/README.md
CHANGED
|
@@ -1,302 +1,61 @@
|
|
|
1
1
|
# @code-partner/codepipe
|
|
2
2
|
|
|
3
|
-
**CodePipe turns
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
build and opens a PR. You control every step from a kanban dashboard (works
|
|
7
|
-
from your phone); the agent does the typing.
|
|
8
|
-
|
|
9
|
-
What you get once a project is connected:
|
|
10
|
-
|
|
11
|
-
- **A task pipeline instead of a chat.** Every task moves through explicit
|
|
12
|
-
phases — analysis → your review → implementation → build check → your
|
|
13
|
-
review → PR — visible as cards on a board. Nothing merges without you.
|
|
14
|
-
- **Approval gates.** At each gate you Approve, Reject with a comment (the
|
|
15
|
-
agent redoes the step with your instruction), or just comment.
|
|
16
|
-
- **Rework by comment.** After the PR exists, reply
|
|
17
|
-
`@codepipe rework: <what to change>` in the YouTrack task — the agent picks
|
|
18
|
-
it up and updates the PR.
|
|
19
|
-
- **Your credentials never leave your machine.** The CLI on your laptop is
|
|
20
|
-
the only thing holding YouTrack and git tokens; the orchestrating HUB has
|
|
21
|
-
no git access and no production tokens at all. Agent runners receive
|
|
22
|
-
read-only access encrypted per job and never persist it.
|
|
23
|
-
- **Works with an empty repo or an existing codebase** — you can start a
|
|
24
|
-
brand-new project or point CodePipe at years of history.
|
|
25
|
-
|
|
26
|
-
One package, one `codepipe` bin, two roles — for solo work you run both on
|
|
27
|
-
your machine with a single command (`codepipe up`):
|
|
28
|
-
|
|
29
|
-
- **CLI** — the local daemon that holds your credentials and performs every
|
|
30
|
-
write (branches, pushes, PRs, tracker updates);
|
|
31
|
-
- **worker** — the agent runner (Claude Code headless) that claims jobs and
|
|
32
|
-
does the analysis/implementation work.
|
|
33
|
-
|
|
34
|
-
---
|
|
35
|
-
|
|
36
|
-
## Before you start: the checklist
|
|
37
|
-
|
|
38
|
-
Everything you need in place before `codepipe init`:
|
|
39
|
-
|
|
40
|
-
1. **Node.js 22+** and **git** on your machine.
|
|
41
|
-
|
|
42
|
-
2. **Claude Code + a Claude subscription.** Agents run on your Claude
|
|
43
|
-
account. Install [Claude Code](https://claude.com/claude-code), make sure
|
|
44
|
-
`claude` is on `PATH`, then run `claude setup-token` and copy the token
|
|
45
|
-
(`sk-ant-…`) — the setup wizard will ask for it.
|
|
46
|
-
|
|
47
|
-
3. **A YouTrack project.** You need three things:
|
|
48
|
-
- the instance URL (e.g. `https://yourteam.youtrack.cloud`);
|
|
49
|
-
- a permanent token: YouTrack → your avatar → *Account Security* →
|
|
50
|
-
*Tokens* → *New token…*;
|
|
51
|
-
- the project key (e.g. `DEV`).
|
|
52
|
-
|
|
53
|
-
The project must have a **`Stage` custom field** (enum) — that is the
|
|
54
|
-
column set CodePipe reads and moves. The default config expects at least
|
|
55
|
-
the values `Backlog`, `Develop` and `Review`: tasks in `Develop` enter the
|
|
56
|
-
pipeline, `Backlog` shows up as the dashboard TODO section, and `Review`
|
|
57
|
-
is where a task is moved once its PR is open. (Column names are
|
|
58
|
-
configurable later in `.codepipe/project.yaml` / `regimen.yaml`.)
|
|
59
|
-
|
|
60
|
-
4. **A project repository** on **GitHub, GitLab or Bitbucket** — empty or
|
|
61
|
-
with existing code, both work — and an access token for that host:
|
|
62
|
-
- **GitHub**: a classic PAT with `repo` + `workflow`, or a fine-grained
|
|
63
|
-
PAT with *Administration RW + Contents RW + Workflows RW + Metadata R*
|
|
64
|
-
(Administration is what lets the wizard create the Context Repo for
|
|
65
|
-
you; if the repos live in an org, approve the token in the org
|
|
66
|
-
settings);
|
|
67
|
-
- **GitLab**: a PAT with `api` (or `read_api` + `write_repository`);
|
|
68
|
-
- **Bitbucket**: your Atlassian account email + a scoped API token
|
|
69
|
-
(id.atlassian.com → *Security* → *API tokens* → *Create API token with
|
|
70
|
-
scopes*, app *Bitbucket*): `read:account`, `read:repository` +
|
|
71
|
-
`write:repository`, `write:pullrequest`, plus `admin:repository` so the
|
|
72
|
-
wizard can create the Context Repo.
|
|
73
|
-
|
|
74
|
-
5. **A CodePipe account** — nothing to prepare: it is created automatically
|
|
75
|
-
during setup from your email. During the beta, new accounts wait for
|
|
76
|
-
operator approval (you get an email when it happens).
|
|
3
|
+
**CodePipe turns tasks into reviewed pull requests.** An AI agent (Claude
|
|
4
|
+
Code) analyzes a task, waits for your approval, implements it and opens a
|
|
5
|
+
PR — every step under your control, from your phone or your terminal.
|
|
77
6
|
|
|
78
7
|
## Install
|
|
79
8
|
|
|
80
9
|
```bash
|
|
81
10
|
npm i -g @code-partner/codepipe
|
|
11
|
+
codepipe init # setup wizard; on finish it starts `codepipe up` itself
|
|
82
12
|
```
|
|
83
13
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
## Step 1 — register the project: `codepipe init`
|
|
88
|
-
|
|
89
|
-
Two ways to start, depending on where your code is:
|
|
90
|
-
|
|
91
|
-
```bash
|
|
92
|
-
# A) fresh workspace — repos will be cloned for you
|
|
93
|
-
mkdir ~/Projects/acme && cd ~/Projects/acme
|
|
94
|
-
codepipe init
|
|
95
|
-
|
|
96
|
-
# B) you already have the code checked out — run it inside the repo
|
|
97
|
-
cd ~/Projects/acme-api
|
|
98
|
-
codepipe init
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
In case B the wizard detects `origin`, prefills the repo questions and
|
|
102
|
-
registers the checkout in place — no duplicate clone; `.codepipe/` is created
|
|
103
|
-
inside the repo and offered for its `.gitignore`.
|
|
104
|
-
|
|
105
|
-
The wizard asks, in order (Ctrl+C is safe at any point — a re-run resumes
|
|
106
|
-
from where you stopped):
|
|
107
|
-
|
|
108
|
-
1. **Where should this project run** — pick `local` for solo work (`farm` is
|
|
109
|
-
for hosting the daemon on a separate always-on machine).
|
|
110
|
-
2. **HUB URL** — accept the default unless you self-host.
|
|
111
|
-
3. **Your account email** — a browser tab opens to confirm this CLI with one
|
|
112
|
-
click; no account yet means one is created and confirmed by email (plus
|
|
113
|
-
operator approval during the beta — the wizard waits, and it is safe to
|
|
114
|
-
Ctrl+C and re-run later).
|
|
115
|
-
4. **Project id and name** — a short slug (e.g. `acme`) and a display name.
|
|
116
|
-
5. **Automation level** — `assisted`: every phase starts only when you press
|
|
117
|
-
Run on the dashboard (recommended to learn the ropes); `full`: tasks run
|
|
118
|
-
end-to-end to a PR, pausing only at gates you keep. You can change it
|
|
119
|
-
later.
|
|
120
|
-
6. **YouTrack URL, token and project key** — checked live before moving on.
|
|
121
|
-
7. **Allow CodePipe to write to YouTrack?** — yes: it moves tasks between
|
|
122
|
-
columns and comments the PR link; no: YouTrack stays strictly read-only
|
|
123
|
-
(you move cards yourself).
|
|
124
|
-
8. **Project repositories** — paste a clone URL per repo; the host token is
|
|
125
|
-
asked once per host and verified live. Connect one repo or several.
|
|
126
|
-
9. **Context Repo** — the git repo where CodePipe keeps its prompts,
|
|
127
|
-
knowledge base and task artifacts (analysis, patches). Accept the default
|
|
128
|
-
name and the wizard **creates it next to your first project repo**; or
|
|
129
|
-
attach to an existing one.
|
|
130
|
-
10. **Your YouTrack login** — only tasks assigned to you enter the pipeline
|
|
131
|
-
(lift the filter later with `require_assignee: false` in
|
|
132
|
-
`.codepipe/project.yaml`).
|
|
133
|
-
11. **Claude OAuth token** — paste the `claude setup-token` output. Skippable,
|
|
134
|
-
but no agent job runs until you set it (`codepipe login` does it later).
|
|
135
|
-
|
|
136
|
-
Then init does the actual setup — this is the "first run" work:
|
|
137
|
-
|
|
138
|
-
- **creates (or attaches to) the Context Repo** on your git host and
|
|
139
|
-
scaffolds it;
|
|
140
|
-
- **registers the project on the HUB** under your account (re-running init
|
|
141
|
-
on an existing project is safe — it reuses it);
|
|
142
|
-
- **clones the Context Repo** into `.codepipe/` and writes your local config
|
|
143
|
-
next to it: `project.yaml` (repos, board columns, sync rules) and
|
|
144
|
-
`regimen.yaml` (automation, gates, build/CI loops) — plain YAML you can
|
|
145
|
-
edit any time;
|
|
146
|
-
- **clones the project repos** as siblings of `.codepipe/` (skipped for an
|
|
147
|
-
in-place init — your checkout is the workspace);
|
|
148
|
-
- **saves secrets** to `~/.codepipe/secrets/<project>.json` (mode 0600 —
|
|
149
|
-
tokens never land in a repo);
|
|
150
|
-
- **offers to index the codebase** — a one-time agent job that writes
|
|
151
|
-
`knowledge/INDEX.md` into the Context Repo, a map of your code that makes
|
|
152
|
-
every later analysis faster and better grounded. Say yes; it runs in the
|
|
153
|
-
background once the daemon and worker are up.
|
|
154
|
-
|
|
155
|
-
## Step 2 — start it: `codepipe up`
|
|
156
|
-
|
|
157
|
-
```bash
|
|
158
|
-
cd ~/Projects/acme # the folder you ran init in
|
|
159
|
-
codepipe up
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
One command, both roles: the CLI daemon connects to the HUB, and an embedded
|
|
163
|
-
agent worker registers itself automatically on the first run (no dashboard
|
|
164
|
-
visit, no manual tokens) and starts claiming jobs. Leave it running while you
|
|
165
|
-
work; Ctrl+C stops both.
|
|
14
|
+
`init` runs `codepipe up` for you at the end — no need to run `up` separately
|
|
15
|
+
after setup.
|
|
166
16
|
|
|
167
|
-
|
|
168
|
-
with the daemon embedded — see the command list below.
|
|
17
|
+
## Requirements
|
|
169
18
|
|
|
170
|
-
|
|
19
|
+
- **Node.js 22+** and **git**.
|
|
20
|
+
- **Claude Code + an active Claude subscription.** Agents run on your Claude
|
|
21
|
+
account: install [Claude Code](https://claude.com/claude-code), make sure
|
|
22
|
+
`claude` is on `PATH`, then run `claude setup-token` — the wizard asks for
|
|
23
|
+
the token.
|
|
24
|
+
- **A git host token** (GitHub / GitLab / Bitbucket) — for branches, pull
|
|
25
|
+
requests and the Context Repo. The wizard tells you which scopes it needs
|
|
26
|
+
and verifies the token live.
|
|
27
|
+
- *Optional:* **podman** — only for the BUILD phase (an automatic
|
|
28
|
+
lint/build/test run before the PR). The solo workflow works without it.
|
|
29
|
+
- **Task tracker — built-in.** CodePipe ships with its own task tracker, so
|
|
30
|
+
there is nothing to set up; connecting YouTrack is optional.
|
|
171
31
|
|
|
172
|
-
|
|
173
|
-
project card is there, with the setup/index progress on it.
|
|
174
|
-
2. In YouTrack, take a task, **assign it to yourself** and move it to
|
|
175
|
-
**`Develop`** (or create it in `Backlog` and press *Develop* on the
|
|
176
|
-
dashboard card).
|
|
177
|
-
3. Watch it on the board: the agent analyzes the task and produces
|
|
178
|
-
`SOLUTION.md` (+ questions, if any). In `assisted` mode press **Run** to
|
|
179
|
-
start each phase.
|
|
180
|
-
4. **Review gate:** read the proposed solution, then Approve — or Reject
|
|
181
|
-
with a comment and get a revised one.
|
|
182
|
-
5. The agent implements, the build check runs lint/build/tests, and after
|
|
183
|
-
your second approval the CLI pushes the branch and **opens the PR**
|
|
184
|
-
(task moves to `Review` with a PR-link comment, if writes are on).
|
|
185
|
-
6. Want changes after reviewing the PR? Comment in the YouTrack task:
|
|
32
|
+
## Commands
|
|
186
33
|
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
34
|
+
| Command | What it does |
|
|
35
|
+
|---|---|
|
|
36
|
+
| `codepipe init` | set up a project (wizard) and start it |
|
|
37
|
+
| `codepipe up` | run the local daemon + agent worker (solo mode) |
|
|
38
|
+
| `codepipe` | open an interactive REPL with the daemon embedded |
|
|
39
|
+
| `codepipe sync` | clone/fetch the project repos |
|
|
40
|
+
| `codepipe login` | set or replace your Claude token |
|
|
41
|
+
| `codepipe clone <id>` | rebuild the workspace on another machine |
|
|
190
42
|
|
|
191
|
-
|
|
43
|
+
Advanced and fleet commands (separate daemon/worker, multi-project farms) are
|
|
44
|
+
covered in the docs.
|
|
192
45
|
|
|
193
|
-
##
|
|
46
|
+
## What happens next
|
|
194
47
|
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
codepipe sync clone/fetch the project repos per project.yaml
|
|
200
|
-
codepipe login set/replace the Claude token (--shared for machine-wide)
|
|
201
|
-
codepipe clone <id> reconstruct the workspace on another machine
|
|
202
|
-
codepipe project move … repoint an initialised project at another HUB
|
|
203
|
-
codepipe worker … run the agent worker separately (see below)
|
|
204
|
-
```
|
|
48
|
+
Create a task (or pick an existing one) and watch it on the board: the agent
|
|
49
|
+
studies your codebase and proposes a solution as `SOLUTION.md`. Nothing moves
|
|
50
|
+
past that point without you — **you Approve**, or Reject with a comment and
|
|
51
|
+
get a revised proposal.
|
|
205
52
|
|
|
206
|
-
|
|
53
|
+
After your approval the agent implements the change, runs its checks and
|
|
54
|
+
opens a **pull request** for you to review. Rework is a comment away: reply
|
|
55
|
+
on the task and the agent updates the PR. Details of the `init` wizard,
|
|
56
|
+
automation levels and everything beyond the solo setup live in the docs.
|
|
207
57
|
|
|
208
|
-
|
|
209
|
-
/status connection, project, Context Repo branch, siblings
|
|
210
|
-
/tasks [--phase P] list tasks
|
|
211
|
-
/task <key> task detail
|
|
212
|
-
/sync clone/fetch project repos per project.yaml
|
|
213
|
-
/apply <key> apply a task patch on a new branch + commit (local mode)
|
|
214
|
-
/unstash <key> apply a task patch uncommitted on the base commit
|
|
215
|
-
/applied <key> --pr U mark applied (repo=URL form for multi-repo tasks)
|
|
216
|
-
/abort <key> --reason roll the local apply back, send the task to the agent
|
|
217
|
-
/secret set|list|unset manage stored tokens
|
|
218
|
-
/quit stop the daemon and exit
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
`/apply` and `/unstash` support the **local apply mode** (`apply.mode: local`
|
|
222
|
-
in `project.yaml`, or per-task with `@codepipe apply: local`): CodePipe never
|
|
223
|
-
pushes for you — you review the staged change locally, commit, push and open
|
|
224
|
-
the PR yourself, then `/applied <key> --pr <url>`.
|
|
225
|
-
|
|
226
|
-
## Running the worker elsewhere (optional)
|
|
227
|
-
|
|
228
|
-
Solo mode embeds the worker, but you can also run it on a separate machine —
|
|
229
|
-
a desktop with spare cores, a home server, a cloud box:
|
|
230
|
-
|
|
231
|
-
```bash
|
|
232
|
-
codepipe worker # interactive wizard on an unregistered machine
|
|
233
|
-
```
|
|
234
|
-
|
|
235
|
-
Log in by email, pick "all my projects" or a subset — runners are bound to
|
|
236
|
-
your account and only serve your projects. Headless servers register
|
|
237
|
-
non-interactively:
|
|
238
|
-
|
|
239
|
-
```bash
|
|
240
|
-
codepipe worker register \
|
|
241
|
-
--hub https://hub.example.com \ # env CODEPIPE_HUB_URL
|
|
242
|
-
--token <registration token> \ # env CODEPIPE_WORKER_REG_TOKEN
|
|
243
|
-
--llm claude-headless # env CODEPIPE_WORKER_LLM
|
|
244
|
-
# --name / CODEPIPE_WORKER_NAME, --projects / CODEPIPE_WORKER_PROJECTS
|
|
245
|
-
# prints the key fingerprint — confirm it on the CLI (pin-on-register)
|
|
246
|
-
|
|
247
|
-
codepipe worker # connect to HUB and run the claim-loop (= worker start)
|
|
248
|
-
```
|
|
249
|
-
|
|
250
|
-
The worker config lives at `~/.codepipe/worker/config.json`
|
|
251
|
-
(`--profile <id>` → `~/.codepipe/worker/profiles/<id>/config.json`;
|
|
252
|
-
`CODEPIPE_SANDBOX_CONFIG` overrides). For the agent backend, Claude Code
|
|
253
|
-
(`claude`) must be on `PATH`. On a fresh Linux server use the installer
|
|
254
|
-
served by your HUB instead
|
|
255
|
-
(`curl -fsSL https://<your-hub>/install-sandbox.sh | sudo bash -s -- …`) —
|
|
256
|
-
it also sets up Node 22, the agent toolchain, rootless Podman, an isolated
|
|
257
|
-
`devpipe` user and systemd units.
|
|
258
|
-
|
|
259
|
-
## Where things live
|
|
260
|
-
|
|
261
|
-
- `.codepipe/` in the workspace — the cloned Context Repo, your local
|
|
262
|
-
`project.yaml` / `regimen.yaml`, plus runtime state (gitignored).
|
|
263
|
-
- Project repos — siblings of `.codepipe/` (or the checkout itself for an
|
|
264
|
-
in-place init).
|
|
265
|
-
- `~/.codepipe/secrets/<project>.json` — tokens, mode 0600, never in a repo.
|
|
266
|
-
- `~/.codepipe/worker/config.json` — worker registration (HUB URL, runner
|
|
267
|
-
id, keypair), mode 0600.
|
|
268
|
-
|
|
269
|
-
## Continuing on another machine
|
|
270
|
-
|
|
271
|
-
```bash
|
|
272
|
-
mkdir ~/Projects/acme && cd ~/Projects/acme
|
|
273
|
-
codepipe clone acme # re-clone the workspace; re-enter your tokens
|
|
274
|
-
```
|
|
275
|
-
|
|
276
|
-
## Moving a project to another HUB
|
|
277
|
-
|
|
278
|
-
When a project graduates from a shared HUB to an enterprise one (or you want to
|
|
279
|
-
try it on a dev stand), `project move` re-registers it on the target HUB without
|
|
280
|
-
the full `init` wizard. Your Context Repo, project config and stored
|
|
281
|
-
credentials are reused as-is; only a fresh account sign-in on the target HUB is
|
|
282
|
-
needed.
|
|
283
|
-
|
|
284
|
-
```bash
|
|
285
|
-
codepipe project move --from-profile acme --hub https://hub.enterprise.example
|
|
286
|
-
```
|
|
287
|
-
|
|
288
|
-
That repoints the `acme` profile in place. To keep the old binding and add a
|
|
289
|
-
second one — e.g. a dev stand alongside prod — write a separate profile:
|
|
290
|
-
|
|
291
|
-
```bash
|
|
292
|
-
codepipe project move --from-profile acme --to-profile acme-dev \
|
|
293
|
-
--hub https://hub.dev.example --project acme-dev
|
|
294
|
-
```
|
|
295
|
-
|
|
296
|
-
The move is non-destructive: the project's registration on the old HUB stays.
|
|
297
|
-
Task history is not copied — the project starts clean on the target HUB — and
|
|
298
|
-
the source HUB must be reachable so the current definition can be read.
|
|
299
|
-
`--account <email>` targets a specific account on the new HUB (defaults to the
|
|
300
|
-
source account); `--yes` skips the confirmation.
|
|
58
|
+
---
|
|
301
59
|
|
|
302
|
-
|
|
60
|
+
Full docs, architecture and the fleet/multi-project setup →
|
|
61
|
+
<https://codepipe.dev>
|