switchman-dev 0.1.8 → 0.1.9

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 CHANGED
@@ -1,65 +1,39 @@
1
1
  # Switchman
2
2
 
3
- **Run 10+ agents on one codebase. Safely.**
3
+ **The operating system for parallel AI development.**
4
4
 
5
5
  [![CI](https://github.com/switchman-dev/switchman/actions/workflows/ci.yml/badge.svg)](https://github.com/switchman-dev/switchman/actions/workflows/ci.yml)
6
6
  [![npm version](https://img.shields.io/npm/v/switchman-dev.svg)](https://www.npmjs.com/package/switchman-dev)
7
7
 
8
- Switchman is the coordination and governance layer for AI-native software teams. It helps you plan work, route tasks across agents, prevent overlap, and land changes safely instead of stitching parallel output back together by hand.
8
+ When you run multiple AI agents on the same repo, they collide, duplicate work, and create risky merges. Switchman gives them leases, scoped ownership, policy gates, queue planning, and governed landing workflows so they can move in parallel without stepping on each other.
9
9
 
10
- When you run multiple agents on the same repo, they need shared coordination or they collide, duplicate work, and create risky merges. Switchman gives them leases, scoped ownership, policy gates, queue planning, and governed landing workflows so they can move in parallel without stepping on each other.
10
+ Questions or feedback? Join the [Discord](https://discord.gg/pnT8BEC4D) · [hello@switchman.dev](mailto:hello@switchman.dev)
11
11
 
12
- In the docs, `workspace` means the folder each agent works in. Some commands still use the Git term `worktree`, because that is the underlying Git feature.
13
-
14
- Questions, feedback, or testing Switchman with your team? Join the [Discord](https://discord.gg/pnT8BEC4D)
12
+ ---
15
13
 
16
14
  ## Install
17
15
 
18
- Requirements:
19
- - Node.js 22.5+
20
- - Git 2.5+
21
-
22
- Why Node 22.5+?
23
- - Switchman uses the built-in `node:sqlite` runtime support for its repo-local coordination database.
24
- - Keeping that dependency in the Node runtime makes install and recovery simpler, but it currently means targeting newer Node releases on purpose.
25
-
26
- TypeScript and API surface
27
- - Switchman is CLI-first today. The supported interface is the `switchman` command and the MCP integration, not a stable embeddable library API yet.
28
- - That means there are no published TypeScript types right now by design. We plan to add typed surfaces once the programmatic API is stable enough to support cleanly.
16
+ Requirements: Node.js 22.5+ · Git 2.5+
29
17
 
30
18
  ```bash
31
19
  npm install -g switchman-dev
32
20
  ```
33
21
 
34
- ## 2 minute proof
22
+ > Switchman uses the built-in `node:sqlite` runtime — no extra database to install or manage.
35
23
 
36
- If you want the fastest possible “does this actually work?” run:
24
+ ---
25
+
26
+ ## 2 minute proof
37
27
 
38
28
  ```bash
39
29
  switchman demo
40
30
  ```
41
31
 
42
- That creates a throwaway repo and shows:
43
- - one agent claiming `src/auth.js`
44
- - another agent getting blocked from claiming the same file
45
- - that second agent rerouting to a safe docs file instead
46
- - both branches landing back through the queue cleanly
47
-
48
- Typical proof output looks like:
49
-
50
- ```text
51
- $ switchman demo
52
- ✓ Created Switchman demo repo
53
- /tmp/switchman-demo-1234567890
54
- proof: agent2 was blocked from src/auth.js
55
- safe reroute: agent2 claimed docs/auth-flow.md instead
56
- landing: 2 queue item(s) merged safely
57
-
58
- Try these next:
59
- cd /tmp/switchman-demo-1234567890
60
- switchman status
61
- switchman queue status
62
- ```
32
+ Creates a throwaway repo and shows:
33
+ - agent1 claiming `src/auth.js`
34
+ - agent2 getting blocked from the same file
35
+ - agent2 rerouting safely to `docs/auth-flow.md`
36
+ - both branches landing cleanly through the queue
63
37
 
64
38
  Then inspect it:
65
39
 
@@ -69,33 +43,37 @@ switchman status
69
43
  switchman queue status
70
44
  ```
71
45
 
72
- ## Why Switchman?
46
+ ---
73
47
 
74
- Git worktrees, branches, and raw coding agents are useful, but they do not coordinate themselves.
48
+ ## Switchman Pro
75
49
 
76
- What it adds that plain Git does not:
77
- - task planning, so incoming goals can be broken into governed parallel work
78
- - task assignment, so agents do not duplicate work
79
- - file locking, so parallel edits do not quietly collide
80
- - live status, so you can see what is running, blocked, or stale
81
- - stale-work recovery, so abandoned work does not clog the repo
82
- - queue intelligence, so the clearest work lands first across competing goals
83
- - governed landing, so finished work reaches `main` one item at a time with retries, checks, and policy enforcement
50
+ > **Unlimited agents · Team coordination · AI planning · $25/month**
51
+ > [switchman.dev/pro](https://switchman.dev/pro) · or run `switchman upgrade`
84
52
 
85
- In short:
86
- - Git gives you branches
87
- - Switchman gives you coordination, governance, and a safe path to land
53
+ Pro removes the 3-agent limit, adds cloud-synced team coordination, AI task planning, and 90-day history. Free tier stays fully featured and MIT licensed forever.
88
54
 
89
- ## Quickstart
55
+ ```bash
56
+ switchman upgrade # open switchman.dev/pro
57
+ switchman login # activate after subscribing
58
+ switchman login --status # check your plan
59
+ ```
60
+
61
+ **What's in Pro:**
62
+ - Unlimited concurrent agents (free: up to 3)
63
+ - Cloud-synced team activity across machines
64
+ - Team invites — `switchman team invite alice@example.com`
65
+ - AI task planning — `switchman plan "Add authentication" --apply`, `switchman plan --issue 47`, and optionally `--comment` back to the issue or PR
66
+ - 90-day audit trail (free: 7 days)
67
+ - Email support within 48 hours
90
68
 
91
- Recommended first run:
92
- - editor: Claude Code
93
- - goal: feel safe parallel agent work in under 10 minutes
94
- - proof: status stays clear, agents stay separated, and the repo gate passes
69
+ **$25/month or $250/year per seat** · [switchman.dev/pro](https://switchman.dev/pro)
70
+
71
+ ---
72
+
73
+ ## Quickstart
95
74
 
96
75
  ```bash
97
76
  cd my-project
98
- switchman demo
99
77
  switchman setup --agents 3
100
78
  switchman task add "Implement auth helper" --priority 9
101
79
  switchman status --watch
@@ -103,89 +81,51 @@ switchman gate ci
103
81
  switchman queue run
104
82
  ```
105
83
 
106
- If you only do five things on the first run, do these:
107
- 1. `switchman demo`
108
- 2. `switchman setup --agents 3`
109
- 3. `switchman task add "Implement auth helper" --priority 9`
110
- 4. `switchman status --watch`
111
- 5. `switchman gate ci && switchman queue run`
112
-
113
84
  What `switchman setup` gives you:
114
- - one shared Switchman database in `.switchman/`
115
- - linked workspaces for each agent
116
- - local MCP config for Claude Code and Cursor
117
-
118
- Current limit:
119
- - `switchman setup --agents` currently supports up to `10` agent workspaces in one command
85
+ - a shared Switchman database in `.switchman/`
86
+ - linked agent workspaces
87
+ - MCP config for Claude Code and Cursor
120
88
 
121
89
  Fastest path to success:
122
- 1. Use Claude Code for the first run.
123
- 2. Run `switchman verify-setup` once so editor wiring is confirmed before you start.
124
- 3. Open one Claude Code window per generated workspace.
125
- 4. Add clear tasks before the agents start.
126
- 5. Let each agent pick up one clearly separate task.
127
- 6. Keep `switchman status --watch` open in another terminal.
128
- 7. Run `switchman gate ci`, then `switchman queue run`, when the tasks finish.
129
-
130
- If you want the recommended editor setup guide, start here:
131
- - [Claude Code setup](docs/setup-claude-code.md)
90
+ 1. Use Claude Code for the first run
91
+ 2. Run `switchman verify-setup` to confirm editor wiring
92
+ 3. Run `switchman claude refresh` to generate a repo-aware `CLAUDE.md`
93
+ 4. Open one Claude Code window per generated workspace
94
+ 5. Add tasks before agents start
95
+ 6. Keep `switchman status --watch` open in a separate terminal
96
+ 7. Run `switchman gate ci && switchman queue run` when tasks finish
132
97
 
133
- If you want a guided demo, see [examples/README.md](examples/README.md).
134
- If you want the deeper multi-task planning and PR workflow, see [docs/pipelines.md](docs/pipelines.md).
98
+ Editor setup guides:
99
+ - [Claude Code](docs/setup-claude-code.md)
100
+ - [Cursor](docs/setup-cursor.md)
101
+ - [Windsurf](docs/setup-windsurf.md)
135
102
 
136
- > Free tier supports up to 3 agents. Run `switchman upgrade` for unlimited.
137
-
138
- ## What good looks like
139
-
140
- You know the first run is working when:
141
- - agents claim different files instead of stepping on each other
142
- - `switchman status` stays calm and readable instead of filling with blocked work
143
- - the landing queue moves finished work safely back toward `main`
144
- - `switchman gate ci` passes cleanly
145
-
146
- That is the moment Switchman should feel different from “just using a few branches.”
147
-
148
- ## Start Here
149
-
150
- If you are trying to decide where to start:
151
- - want the fastest proof: run `switchman demo`
152
- - want to wire up a real repo: run `switchman setup --agents 3`
153
- - want to add real work: run `switchman task add "Your task" --priority 8`
154
- - want to understand blocked or stale work: run `switchman status`
155
- - want a longer hands-on walkthrough: open [examples/README.md](examples/README.md)
156
-
157
- ## Enforcement Gateway
103
+ ---
158
104
 
159
- Switchman is strongest when agents write through the governed gateway instead of editing files directly.
105
+ ## Why Switchman?
160
106
 
161
- - MCP agents should prefer `switchman_write_file`, `switchman_append_file`, `switchman_make_directory`, `switchman_move_path`, and `switchman_remove_path`
162
- - CLI operators can use `switchman write` and `switchman wrap` for governed writes and wrapped commands
163
- - `switchman monitor` is started automatically by `switchman setup` unless you opt out, so rogue edits are detected in the background
107
+ Git gives you branches. Switchman gives you coordination.
164
108
 
165
- That closes the gap between "please follow the claiming protocol" and "Switchman can actually catch ungoverned writes when something goes wrong."
109
+ Branches and worktrees solve isolation they do not tell you:
110
+ - which task each agent should take next
111
+ - who already owns a file
112
+ - whether a session is stale
113
+ - whether finished work is safe to land
166
114
 
167
- ## The Workflow
115
+ Switchman adds:
116
+ - **Task planning** — break goals into governed parallel work
117
+ - **File locking** — parallel edits don't quietly collide
118
+ - **Live status** — see what's running, blocked, or stale
119
+ - **Stale recovery** — abandoned work gets detected and requeued
120
+ - **Governed landing** — finished work reaches `main` one item at a time with retries and policy checks
168
121
 
169
- Switchman is built for the workflow of turning multiple competing engineering goals into coordinated parallel execution and a trusted, dependency-aware path to merge.
122
+ Switchman is for the point where "we can manage this by hand" stops being true.
170
123
 
171
- In practice, that means it helps teams:
172
- - break work into parallel tasks
173
- - assign work across agents and humans
174
- - stop overlapping edits early
175
- - detect stale or drifted work before merge chaos
176
- - route validation and governance follow-ups
177
- - decide what should land next
178
- - leave an audit trail of what happened and why
124
+ ---
179
125
 
180
126
  ## Real-World Walkthrough
181
127
 
182
- Here is what a real first team workflow can look like across several goals in one shared repo:
183
-
184
- 1. Product work arrives:
185
- - harden auth flows
186
- - ship a schema update
187
- - refresh related docs
188
- 2. You create parallel work:
128
+ Three goals arrive at once: harden auth, ship a schema update, refresh docs.
189
129
 
190
130
  ```bash
191
131
  switchman setup --agents 5
@@ -195,28 +135,16 @@ switchman task add "Update auth and schema docs" --priority 6
195
135
  switchman status --watch
196
136
  ```
197
137
 
198
- 3. Agents pick up work in separate workspaces:
199
- - agent1 takes auth
200
- - agent2 takes the migration
201
- - agent3 takes docs
202
- 4. If two agents reach for the same file, Switchman blocks the second claim early instead of letting the overlap turn into merge cleanup later.
203
- 5. While work is running, `switchman status` shows:
204
- - what is active
205
- - what is blocked
206
- - what has gone stale
207
- - what should land next
208
- 6. When branches finish, queue them:
138
+ Agents pick up work in separate workspaces. If two reach for the same file, Switchman blocks the second claim early. When branches finish:
209
139
 
210
140
  ```bash
211
141
  switchman queue add agent1
212
142
  switchman queue add agent2
213
143
  switchman queue add agent3
214
- switchman queue status
215
144
  switchman queue run --follow-plan --merge-budget 2
216
145
  ```
217
146
 
218
- 7. If a shared change invalidates another task, Switchman marks it stale and points at the exact recovery command instead of leaving the team to guess.
219
- 8. Before merge, run the repo gate:
147
+ Before merge:
220
148
 
221
149
  ```bash
222
150
  switchman gate ci
@@ -225,210 +153,97 @@ switchman gate ci
225
153
  What good looks like:
226
154
  - each agent stayed in its own lane
227
155
  - overlap was blocked before wasted work spread
228
- - stale work was visible instead of silently wrong
229
156
  - the queue made it obvious what should land now and what should wait
230
- - the repo reached `main` through a governed path instead of manual merge babysitting
231
-
232
- ## Why not just use branches or worktrees?
233
-
234
- Because branches and worktrees solve isolation, not coordination.
235
-
236
- They do not tell you:
237
- - which task each agent should take next
238
- - who already owns a file
239
- - whether a session is stale
240
- - whether finished work is still safe to land
157
+ - the repo reached `main` through a governed path
241
158
 
242
- Switchman is for the point where “we can manage this by hand” stops being true.
243
-
244
- ## Safety note on `--force`
245
-
246
- `switchman claim --force` exists for manual recovery, not normal operation.
247
-
248
- Legitimate use:
249
- - you have already confirmed the conflicting claim is stale, abandoned, or otherwise incorrect
250
- - you are performing operator-led cleanup and need to unblock the repo deliberately
251
-
252
- Not a legitimate use:
253
- - "the other agent is probably done"
254
- - "I just want to keep moving"
255
- - "we'll clean it up in the PR later"
256
-
257
- Normal path:
258
- 1. run `switchman status`
259
- 2. run `switchman explain claim <path>`
260
- 3. reap or retry the stale work if needed
261
- 4. only then use `--force` if you intentionally want to override a known-bad claim
262
-
263
- If that feels too risky, that is the point. It is meant to be an escape hatch, not a convenience flag.
264
-
265
- ## Releases and changelog
266
-
267
- If you want to track what changed between versions:
268
- - [CHANGELOG.md](CHANGELOG.md)
269
- - [GitHub releases](https://github.com/switchman-dev/switchman/releases)
270
-
271
- ## What's included today
272
-
273
- Today Switchman already includes:
274
- - agent worktree setup and repo verification
275
- - lease, claim, heartbeat, and stale-reap coordination
276
- - governed write gateways and a rogue-edit monitor
277
- - repo status, repair, queue planning, and safe landing
278
- - pipeline planning, execution, PR bundles, and GitHub sync
279
- - audit trail, change policy enforcement, and CI integration
280
- - MCP support for Claude Code, Cursor, and Windsurf
281
-
282
- ## Switchman Pro
159
+ ---
283
160
 
284
- Pro gives you unlimited agents, cloud-synced team coordination, and 90-day history.
285
-
286
- ```bash
287
- switchman upgrade # open switchman.dev/pro in your browser
288
- switchman login # activate Pro after subscribing
289
- switchman login --status # check your current plan
290
- ```
291
-
292
- **What's included in Pro:**
293
- - Unlimited concurrent agents (free tier: up to 3)
294
- - Cloud-synced task queues and lease state across your team
295
- - Team invites — `switchman team invite alice@example.com`
296
- - AI task planning — `switchman plan "Add authentication"` proposes parallel tasks from an explicit goal
297
- - 90-day audit trail (free tier: 7 days)
298
- - Email support within 48 hours
299
-
300
- **Pricing:** $25/month or $250/year per seat · [switchman.dev/pro](https://switchman.dev/pro)
301
-
302
- After subscribing, activate in your terminal:
303
- ```bash
304
- switchman login
305
- # Opens GitHub sign-in, saves credentials locally
306
- # Credentials cached 24h · works offline for 7 days
161
+ ## Enforcement Gateway
307
162
 
308
- switchman setup --agents 10
309
- # Pro removes the 3-agent limit
310
- ```
163
+ Switchman is strongest when agents write through the governed gateway instead of editing files directly.
311
164
 
312
- ### Pro planning launch order
165
+ - MCP agents should prefer `switchman_write_file`, `switchman_append_file`, `switchman_make_directory`, `switchman_move_path`, and `switchman_remove_path`
166
+ - CLI operators can use `switchman write` and `switchman wrap`
167
+ - `switchman monitor` runs automatically in the background to catch rogue edits
313
168
 
314
- Switchman Pro planning ships in this order:
315
- - `switchman plan "goal"` first
316
- - `switchman plan --issue 47` next
317
- - zero-argument `switchman plan` later, once real usage data makes that inference trustworthy
169
+ ---
318
170
 
319
- Today, the supported Pro planning flow is:
171
+ ## If something feels stuck
320
172
 
321
173
  ```bash
322
- switchman plan "Add authentication"
323
- switchman plan "Add authentication" --apply
174
+ switchman status # main dashboard
175
+ switchman status --watch # live view
176
+ switchman scan # conflict scan
177
+ switchman gate ci # repo gate check
324
178
  ```
325
179
 
326
- ## What's next
327
-
328
- The next product steps are:
329
- - `switchman plan --issue 47`
330
- - a more magical zero-argument planning flow that can read richer repo and issue context
331
- - a web dashboard for repo and landing visibility
332
- - a Homebrew install path for faster first-run setup
333
-
334
- ## Choose your setup
335
-
336
- Pick the guide that matches how you work:
337
-
338
- | Setup | Guide |
339
- |------|------|
340
- | Claude Code | [Claude Code setup](docs/setup-claude-code.md) |
341
- | Cursor | [Cursor setup](docs/setup-cursor.md) |
342
- | Windsurf | [Windsurf setup](docs/setup-windsurf.md) |
343
- | Any CLI-driven agent | [CLI agent setup](docs/setup-cli-agents.md) |
344
-
345
- ## If something feels stuck
346
-
347
- Use `switchman status` first.
348
-
349
- It is the main terminal dashboard for the repo:
350
- - top health banner and compact counts
351
- - boxed sections for `Running`, `Blocked`, `Warnings`, `Queue`, and `Next action`
352
- - exact follow-up commands when something needs attention
353
- - `--watch` mode for a live terminal view
354
-
355
- Useful commands:
180
+ Explain commands:
356
181
 
357
182
  ```bash
358
- switchman status
359
- switchman status --watch
360
- switchman status --json
361
- switchman scan
362
- switchman gate ci
183
+ switchman explain claim src/auth/login.js
184
+ switchman explain queue <item-id>
185
+ switchman explain stale --pipeline <pipeline-id>
186
+ switchman explain landing <pipeline-id>
363
187
  ```
364
188
 
365
189
  More help:
366
190
  - [Status and recovery](docs/status-and-recovery.md)
367
191
  - [Merge queue](docs/merge-queue.md)
368
- - [Stale lease policy](docs/stale-lease-policy.md)
192
+ - [Pipelines and PRs](docs/pipelines.md)
369
193
  - [Telemetry](docs/telemetry.md)
194
+ - [Command reference](docs/command-reference.md)
370
195
 
371
- The most useful explain commands when something is unclear:
372
-
373
- ```bash
374
- switchman explain claim src/auth/login.js
375
- switchman explain queue <item-id>
376
- switchman explain stale --pipeline <pipeline-id>
377
- switchman explain landing <pipeline-id>
378
- ```
196
+ ---
379
197
 
380
- ## Turn On PR Checks
198
+ ## PR Checks
381
199
 
382
- If you want GitHub to block risky changes the same way your local terminal does:
200
+ Block risky changes in GitHub the same way your local terminal does:
383
201
 
384
202
  ```bash
385
203
  switchman gate install-ci
386
204
  ```
387
205
 
388
- That installs `.github/workflows/switchman-gate.yml`, which:
389
- - runs `switchman gate ci --github` on pushes and pull requests
390
- - auto-runs `switchman pipeline sync-pr --pipeline-from-env --skip-missing-pipeline --pr-from-env --github` on pull request updates
391
- - publishes a readable Switchman summary into the GitHub job output
392
- - fails the PR check when Switchman detects unmanaged changes, stale work, or risky overlap
206
+ Installs `.github/workflows/switchman-gate.yml` — runs the repo gate on every push and PR.
393
207
 
394
- For pipeline-specific landing state in GitHub job summaries or PR checks, use:
208
+ ---
395
209
 
396
- ```bash
397
- switchman pipeline bundle pipe-123 --github
398
- ```
210
+ ## Change Policy
399
211
 
400
- If you want one command that bundles artifacts, updates the PR comment, and emits GitHub outputs together:
212
+ Enforce review or validation for high-risk areas like auth, schema, or payments:
401
213
 
402
214
  ```bash
403
- switchman pipeline sync-pr pipe-123 --pr-from-env --github
215
+ switchman policy init-change
216
+ switchman policy show-change
404
217
  ```
405
218
 
406
- ## Add Change Policy
219
+ ---
407
220
 
408
- If you want Switchman to enforce extra review or validation for high-risk areas like auth, schema, or payments:
221
+ ## What's next
409
222
 
410
- ```bash
411
- switchman policy init-change
412
- switchman policy show-change
413
- ```
223
+ - Zero-argument `switchman plan` — reads full repo context automatically
224
+ - Live web dashboard for repo and agent visibility
225
+ - Homebrew install path
414
226
 
415
- That writes `.switchman/change-policy.json`, which planning and follow-up generation use to require the right tests, docs, and governance work before landing.
227
+ ---
416
228
 
417
- ## More docs
229
+ ## What's included today
418
230
 
419
- - [Merge queue](docs/merge-queue.md)
420
- - [Pipelines and PRs](docs/pipelines.md)
421
- - [Stale lease policy](docs/stale-lease-policy.md)
422
- - [MCP tools](docs/mcp-tools.md)
423
- - [Telemetry](docs/telemetry.md)
424
- - [Command reference](docs/command-reference.md)
231
+ - Agent worktree setup and repo verification
232
+ - Lease, claim, heartbeat, and stale-reap coordination
233
+ - Governed write gateways and rogue-edit monitor
234
+ - Repo status, repair, queue planning, and safe landing
235
+ - Pipeline planning, execution, PR bundles, and GitHub sync
236
+ - Audit trail, change policy enforcement, and CI integration
237
+ - MCP support for Claude Code, Cursor, and Windsurf
238
+
239
+ ---
425
240
 
426
241
  ## Feedback
427
242
 
428
- Building this in public. If you're running parallel agents and hit something broken or missing, Id love to hear about it.
243
+ Building this in public. If you hit something broken or missing, I'd love to hear about it.
429
244
 
430
- - GitHub Issues: [github.com/switchman-dev/switchman/issues](https://github.com/switchman-dev/switchman/issues)
431
- - Email: [hello@switchman.dev](mailto:hello@switchman.dev)
245
+ - [GitHub Issues](https://github.com/switchman-dev/switchman/issues)
246
+ - [hello@switchman.dev](mailto:hello@switchman.dev)
432
247
 
433
248
  ## License
434
249
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "switchman-dev",
3
- "version": "0.1.8",
3
+ "version": "0.1.9",
4
4
  "description": "Project manager for AI coding assistants running safely on one codebase",
5
5
  "type": "module",
6
6
  "main": "src/index.js",
@@ -0,0 +1,77 @@
1
+ export function registerAuditCommands(program, {
2
+ buildPipelineHistoryReport,
3
+ chalk,
4
+ getDb,
5
+ getRepo,
6
+ printErrorWithNext,
7
+ statusBadge,
8
+ verifyAuditTrail,
9
+ }) {
10
+ const auditCmd = program.command('audit').description('Inspect and verify the tamper-evident audit trail');
11
+ auditCmd._switchmanAdvanced = true;
12
+
13
+ auditCmd
14
+ .command('change <pipelineId>')
15
+ .description('Show a signed, operator-friendly history for one pipeline')
16
+ .option('--json', 'Output raw JSON')
17
+ .action((pipelineId, options) => {
18
+ const repoRoot = getRepo();
19
+ const db = getDb(repoRoot);
20
+
21
+ try {
22
+ const report = buildPipelineHistoryReport(db, repoRoot, pipelineId);
23
+ db.close();
24
+
25
+ if (options.json) {
26
+ console.log(JSON.stringify(report, null, 2));
27
+ return;
28
+ }
29
+
30
+ console.log(chalk.bold(`Audit history for pipeline ${report.pipeline_id}`));
31
+ console.log(` ${chalk.dim('title:')} ${report.title}`);
32
+ console.log(` ${chalk.dim('events:')} ${report.events.length}`);
33
+ console.log(` ${chalk.yellow('next:')} ${report.next_action}`);
34
+ for (const event of report.events.slice(-20)) {
35
+ const status = event.status ? ` ${statusBadge(event.status).trim()}` : '';
36
+ console.log(` ${chalk.dim(event.created_at)} ${chalk.cyan(event.label)}${status}`);
37
+ console.log(` ${event.summary}`);
38
+ }
39
+ } catch (err) {
40
+ db.close();
41
+ printErrorWithNext(err.message, `switchman pipeline status ${pipelineId}`);
42
+ process.exitCode = 1;
43
+ }
44
+ });
45
+
46
+ auditCmd
47
+ .command('verify')
48
+ .description('Verify the audit log hash chain and project signatures')
49
+ .option('--json', 'Output verification details as JSON')
50
+ .action((options) => {
51
+ const repo = getRepo();
52
+ const db = getDb(repo);
53
+ const result = verifyAuditTrail(db);
54
+
55
+ if (options.json) {
56
+ console.log(JSON.stringify(result, null, 2));
57
+ process.exit(result.ok ? 0 : 1);
58
+ }
59
+
60
+ if (result.ok) {
61
+ console.log(chalk.green(`Audit trail verified: ${result.count} signed events in order.`));
62
+ return;
63
+ }
64
+
65
+ console.log(chalk.red(`Audit trail verification failed: ${result.failures.length} problem(s) across ${result.count} events.`));
66
+ for (const failure of result.failures.slice(0, 10)) {
67
+ const prefix = failure.sequence ? `#${failure.sequence}` : `event ${failure.id}`;
68
+ console.log(` ${chalk.red(prefix)} ${failure.reason_code}: ${failure.message}`);
69
+ }
70
+ if (result.failures.length > 10) {
71
+ console.log(chalk.dim(` ...and ${result.failures.length - 10} more`));
72
+ }
73
+ process.exit(1);
74
+ });
75
+
76
+ return auditCmd;
77
+ }
@@ -0,0 +1,37 @@
1
+ export function registerClaudeCommands(program, {
2
+ chalk,
3
+ existsSync,
4
+ getRepo,
5
+ join,
6
+ renderClaudeGuide,
7
+ writeFileSync,
8
+ }) {
9
+ const claudeCmd = program.command('claude').description('Generate or refresh Claude Code instructions for this repo');
10
+
11
+ claudeCmd
12
+ .command('refresh')
13
+ .description('Generate a repo-aware CLAUDE.md for this repository')
14
+ .option('--print', 'Print the generated guide instead of writing CLAUDE.md')
15
+ .addHelpText('after', `
16
+ Examples:
17
+ switchman claude refresh
18
+ switchman claude refresh --print
19
+ `)
20
+ .action((opts) => {
21
+ const repoRoot = getRepo();
22
+ const claudeGuidePath = join(repoRoot, 'CLAUDE.md');
23
+ const content = renderClaudeGuide(repoRoot);
24
+
25
+ if (opts.print) {
26
+ process.stdout.write(content);
27
+ return;
28
+ }
29
+
30
+ const existed = existsSync(claudeGuidePath);
31
+ writeFileSync(claudeGuidePath, content, 'utf8');
32
+ console.log(`${chalk.green('✓')} ${existed ? 'Refreshed' : 'Created'} ${chalk.cyan(claudeGuidePath)}`);
33
+ console.log(` ${chalk.dim('next:')} ${chalk.cyan('switchman verify-setup')}`);
34
+ });
35
+
36
+ return claudeCmd;
37
+ }