@damn-dev/cli 0.15.1 → 0.19.4

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
@@ -5,10 +5,13 @@ Self-hosted workspace OS for human + AI agent collaboration.
5
5
  ## Install
6
6
 
7
7
  ```sh
8
- npm install -g @damn-dev/cli
8
+ pnpm add -g @damn-dev/cli
9
9
  ```
10
10
 
11
- This installs the `damn-dev` command. Requires **Node.js 18+**.
11
+ This installs the `damn-dev` command. Requires **Node.js 22+**. Install with
12
+ **pnpm**, not npm — a native dependency (`impit`, pulled in by browser-builtin)
13
+ ships an `only-allow pnpm` guard that fails npm-based installs. If you don't have
14
+ pnpm, `corepack enable pnpm` (bundled with Node 22) provides it.
12
15
 
13
16
  You will also need **OpenClaw** (the agent runtime):
14
17
 
@@ -62,7 +65,7 @@ From the CLI:
62
65
 
63
66
  ```sh
64
67
  damn-dev stop
65
- npm install -g @damn-dev/cli@latest
68
+ pnpm add -g @damn-dev/cli@latest
66
69
  damn-dev start
67
70
  ```
68
71
 
@@ -53,7 +53,7 @@ function run(args) {
53
53
  if (!fs.existsSync(BACKEND_ENTRY)) {
54
54
  console.error(`[damn.dev] Bundled backend not found at ${BACKEND_ENTRY}.`)
55
55
  console.error('[damn.dev] This usually means the package was installed from a broken tarball.')
56
- console.error('[damn.dev] Try: npm install -g @damn-dev/cli@latest')
56
+ console.error('[damn.dev] Try: pnpm add -g @damn-dev/cli@latest')
57
57
  process.exit(1)
58
58
  }
59
59
  if (!fs.existsSync(PRISMA_SCHEMA)) {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@damn-dev/cli",
3
- "version": "0.15.1",
3
+ "version": "0.19.4",
4
4
  "description": "damn.dev — self-hosted workspace OS for human + AI agent collaboration.",
5
5
  "license": "Apache-2.0",
6
6
  "homepage": "https://damn.dev",
@@ -32,6 +32,7 @@
32
32
  "@fastify/static": "^7.0.4",
33
33
  "@prisma/client": "^6.0.0",
34
34
  "@trpc/server": "^11.0.0",
35
+ "@whiskeysockets/baileys": "7.0.0-rc13",
35
36
  "adm-zip": "^0.5.16",
36
37
  "archiver": "^7.0.1",
37
38
  "better-auth": "^1.5.4",
@@ -41,8 +42,11 @@
41
42
  "fastify": "^4.28.1",
42
43
  "fastify-plugin": "^5.0.0",
43
44
  "grammy": "^1.41.1",
45
+ "mammoth": "^1.12.0",
46
+ "pdf-parse": "^2.4.5",
44
47
  "playwright-core": "^1.59.1",
45
48
  "prisma": "^6.0.0",
49
+ "qrcode": "^1.5.4",
46
50
  "web-push": "^3.6.7",
47
51
  "ws": "^8.18.0",
48
52
  "yaml": "^2.8.2",
@@ -275,6 +275,36 @@ When `Settings → Workspace → Test Mode` is ON:
275
275
  When the user turns Test Mode off, the `## Testing Mode` section is cleanly
276
276
  removed from every agent's `AGENTS.md`.
277
277
 
278
+ ## Oversight (Trace · Policy · Pending)
279
+
280
+ The operator/CISO governance surface, at the **Oversight** icon in the sidebar
281
+ (a speedometer/gauge). One page, three tabs:
282
+
283
+ - **Pending** — the live approval queue (what needs a human decision now). Filter
284
+ by agent. This replaces the old standalone "Approvals" panel.
285
+ - **Trace** — the immutable, tamper-evident **audit log**: every meaningful action
286
+ recorded with who/what/when. Captures agent work (shell commands), approval
287
+ decisions, and **configuration changes** (agent created/edited/deleted, abilities
288
+ enabled/disabled, policy changes) — config changes are flagged as the **drift
289
+ signal**. Filter by category or by agent; export as NDJSON for an auditor; an
290
+ integrity badge confirms the chain hasn't been tampered with. It is the system
291
+ of record — "what are the agents set up to do, what did they actually do, and
292
+ what changed."
293
+ - **Policy** — the CISO-configurable governance policy (what employees and their
294
+ agents may do): which actions employees can self-approve vs. escalate,
295
+ capabilities (shell/browsing/external messaging), keep-sensitive-data-on-local-
296
+ models, visibility, budgets, agent lifecycle. Pick a template (Regulated /
297
+ Standard / Open) and tune. Granular auto-approve rules live here too.
298
+
299
+ **Who sees what.** Oversight is visible to everyone but role-scoped: **operators**
300
+ (owner/admin) see the whole workspace, edit policy, export, and verify; **daily
301
+ users** (members) see *their own* activity in Trace and a *read-only* Policy. The
302
+ boundary is enforced server-side, not just hidden in the UI.
303
+
304
+ When the user asks "what did my agents do?", "did anything change/drift?", "who
305
+ approved X?", or "what are employees allowed to do?", point them to **Oversight**.
306
+ This is damn.dev's enterprise governance layer and a core differentiator.
307
+
278
308
  ## Skills
279
309
  Three sources:
280
310
  - **ClawHub** — community marketplace. Browse and install from the Skills page.
@@ -431,6 +461,22 @@ trust-update blocks. Mounts are reflected in SOUL.md `## File Access` with
431
461
  git context (remote URL, branch) when a git repo is detected. Mounts support
432
462
  `ro` (read-only, default) and `rw` (read & write) modes.
433
463
 
464
+ ## Channel Files-in-Context (0.19.0+)
465
+ Any channel can have files pinned to it via the files button in the channel
466
+ header. Pinned files are shared context for every human and agent in that
467
+ channel — distinct from per-message attachments (which apply only to the
468
+ message they're sent with). File types: anything (documents, images, data).
469
+
470
+ Consumption is **on-demand**, not auto-loaded: an agent's prompt receives a
471
+ `## Channel Context Files` manifest listing each pinned file's `attachmentId`,
472
+ filename, and type, plus instructions to fetch content only when relevant. To
473
+ read a pinned file, the agent calls `skill_exec(slug: 'channel-context-builtin',
474
+ args: { tool: 'read', attachmentId: '<id>' })`. Text/PDF/DOCX return extracted
475
+ text (truncated at ~30k chars); images return as native vision input. The read
476
+ tool is auto-approved (read-tier) and the `channel-context-builtin` skill is
477
+ always-on for every agent — no manual enabling needed. A file can only be read
478
+ from the channel it's pinned to (cross-channel reads are refused).
479
+
434
480
  ## Integrations
435
481
  Settings → Integrations provides one-click setup for external tools. Each
436
482
  integration handles env vars, volume mounts, skill installation, and agent
@@ -544,11 +590,20 @@ External channel bridges are configured in each agent's Channels tab.
544
590
  Messages from external channels flow through the full pipeline — approvals,
545
591
  audit trail, delegation, and block parsing all work identically.
546
592
 
547
- Current supported channels: Telegram (with grammY). Multi-user pairing supported.
548
- WhatsApp, Discord, and Slack are planned.
593
+ Current supported channels: Telegram (grammY) and WhatsApp (Baileys bridge).
594
+ Discord and Slack are planned. Both Telegram and WhatsApp support multi-user pairing.
549
595
 
550
- When a user asks about connecting agents to Telegram, direct them to the agent's
551
- Channels tab. Do not suggest configuring OpenClaw's native channel settings.
596
+ WhatsApp: each agent links its own number by scanning a QR (Agent Channels tab →
597
+ Connect WhatsApp), exactly like a per-agent Telegram bot. Two inbox modes: Open
598
+ (anyone who messages the number gets their own private thread and a reply — a
599
+ support/business line) or Invite-only (only people who send a pairing code can reach
600
+ the agent). Each WhatsApp contact appears as its own tab under a single "WhatsApp"
601
+ inbox channel in the sidebar; clicking a sender's name shows a read-only contact card
602
+ (phone, first/last seen, message count, and whether they're a known workspace member
603
+ or a prospect). CRM depth lives in chut.co, not damn.dev.
604
+
605
+ When a user asks about connecting agents to Telegram or WhatsApp, direct them to the
606
+ agent's Channels tab. Do not suggest configuring OpenClaw's native channel settings.
552
607
 
553
608
  ## Scheduling (Heartbeats)
554
609
  Agents can run scheduled tasks via their agent panel → Schedule tab. When enabled,
@@ -703,6 +758,25 @@ stress-testing; the purge tool handles surprises.
703
758
 
704
759
  Import/export from the agent panel or team settings.
705
760
 
761
+ ## Import from OpenClaw
762
+ Users migrating from a vanilla OpenClaw install can bring their existing agents
763
+ into damn.dev — soul, identity, memory, knowledge, skills, and heartbeat all
764
+ preserved. The importer scans `~/.openclaw` on the host, lists each agent it
765
+ finds, and imports the selected ones on demand. It is **dry-run until the user
766
+ clicks Import** — nothing is written during the scan.
767
+
768
+ Two surfaces, same flow:
769
+ - **Onboarding** — a step that appears *only* when the scan finds at least one
770
+ not-yet-imported OpenClaw agent. Fresh users with no prior OpenClaw setup never
771
+ see it.
772
+ - **Settings → Workspace → "Import from OpenClaw"** — always available, so users
773
+ who skipped onboarding (or added OpenClaw agents later) can still migrate.
774
+
775
+ Already-imported agents are greyed out; a "re-import (overwrite)" toggle forces a
776
+ true overwrite of soul/identity/skills. Imported agents land with shell tools
777
+ denied, sandbox off, and the standard governance wiring — identical to natively
778
+ created agents. The `coo` agent is never migrated (it's auto-seeded per install).
779
+
706
780
  ## Agent Creation
707
781
  Ask the COO to design agent teams: "I need an agent that handles customer support."
708
782
  The COO proposes the full setup — agents, skills, channel assignments — and you
@@ -894,9 +968,11 @@ on another machine, point them at the right one:
894
968
  - **Docker** (recommended for most users) — `curl -fsSL install.damn.dev/docker | bash`.
895
969
  Native backend + Dockerized OpenClaw. Works on macOS, Linux. Auto-updates
896
970
  via in-app banner.
897
- - **npm** (devs who have Node 18+) — `curl -fsSL install.damn.dev/npm | bash` or
898
- `npm install -g @damn-dev/cli` then `damn-dev start`. `@damn-dev/cli` is the
899
- canonical npm package; the binary is `damn-dev`. Auto-updates via in-app banner.
971
+ - **npm** (devs who have Node 22+) — `curl -fsSL install.damn.dev/npm | bash` or,
972
+ manually, `pnpm add -g @damn-dev/cli` then `damn-dev start`. Install with **pnpm**,
973
+ not npm: a native dependency (`impit`, via browser-builtin) ships an `only-allow
974
+ pnpm` guard that fails npm-based installs. `@damn-dev/cli` is the canonical
975
+ package; the binary is `damn-dev`. Auto-updates via in-app banner.
900
976
  - **Tauri desktop app** — download the DMG (macOS) / deb / rpm from
901
977
  https://github.com/LethoDeter/damn-dev-install/releases/latest. Native app
902
978
  with system tray, in-app updater polls for new releases automatically.
@@ -933,8 +1009,9 @@ the rest is automatic.
933
1009
  as the network heals.
934
1010
  - **Per-step failure messages.** When an update fails, the banner shows WHICH
935
1011
  step failed (e.g. `Step 'compose-pull' failed: <stderr>`). Common diagnoses:
936
- - `npm-install-cli` failure → user's npm prefix likely needs sudo (Mac default
937
- `/usr/local`); they should `npm config set prefix ~/.npm-global` once.
1012
+ - `pnpm-install-cli` failure → pnpm/corepack couldn't install the CLI. Confirm
1013
+ `corepack` is available (it ships with Node 22; `corepack enable` if not) and
1014
+ that pnpm's global bin dir is on PATH.
938
1015
  - `compose-pull` failure → Docker daemon unreachable or network timeout. Have
939
1016
  them confirm `docker info` works.
940
1017
  - `compose-up` failure → port conflict or compose syntax issue. `docker
@@ -0,0 +1,33 @@
1
+ ---
2
+ name: "channel-context-builtin"
3
+ description: "Read files that users or agents have pinned to the current channel for shared reference. When a turn includes a '## Channel Context Files' manifest, those files are available but NOT loaded into context — call this skill to read one on demand. Text, Markdown, JSON, CSV, PDF, and DOCX return extracted text; images return as a viewable picture."
4
+ version: "1.0.0"
5
+ required_secrets: []
6
+ required_tools: []
7
+ tools:
8
+ - name: read
9
+ description: "Read one file pinned to the current channel. Pass the attachment `id` exactly as it appears in the '## Channel Context Files' manifest for this turn (the backticked value). Documents (txt/md/json/csv/pdf/docx) return their extracted text — truncated to ~30k characters for very large files, with `truncated: true` set. Images (png/jpeg/gif/webp) are routed back as a native vision input so you can actually see them. Only files pinned to THIS channel are readable; ids from other channels are rejected."
10
+ parameters:
11
+ - name: attachmentId
12
+ type: string
13
+ description: "The attachment id from the '## Channel Context Files' manifest (the value inside backticks). REQUIRED."
14
+ required: true
15
+ endpoint: inprocess://channel-context-builtin/read
16
+ method: POST
17
+ requires_approval: false
18
+ ---
19
+
20
+ # Channel Context Files
21
+
22
+ Users and agents can pin files to a channel via the channel header's Files button. Pinned files are shared reference material for everyone in the channel — they are listed in a `## Channel Context Files` manifest at the start of a turn but are **never** auto-loaded into your context.
23
+
24
+ When you need the contents of a pinned file, call:
25
+
26
+ ```
27
+ skill_exec({ slug: 'channel-context-builtin', args: { tool: 'read', attachmentId: '<id>' } })
28
+ ```
29
+
30
+ - Use the exact `id` shown in the manifest.
31
+ - Documents come back as extracted text. Large files are truncated (`truncated: true`).
32
+ - Images come back as a native vision input — you'll see the picture directly.
33
+ - You can only read files pinned to the channel you're currently in.