autodsh

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-01），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

# autodsh — Automation Task Plugin for DeepSeek Harness

> ⚠️ **AI Development Notice**: This project was developed with AI assistance
> (DeepSeek Harness coding agent). Code, comments, and documentation contain
> AI-generated content, reviewed by humans and multiple automated review
> rounds. The publisher takes responsibility for the final content.

autodsh is an automation-task plugin for [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness).
Users create automation tasks through conversation; each task follows a
three-part architecture — **trigger + automation content + result
notification** — managed from a unified task panel.

## Features

| Capability | Description |
| --- | --- |
| Persistence | Tasks and run history persist to `$DSH_HOME/storages/autodsh.json` (official storage-domain + JSON backend, atomic writes) |
| Lifecycle | The plugin starts/stops with DSH; enabled tasks resume scheduling automatically on startup |
| Triggers | Fixed interval, cron schedule, condition (last status / last duration / time window), parent-child |
| Execution isolation | Each task runs in its own agent session and working directory; child tasks inherit the parent's workspace and run context |
| Run statistics | Run count, total duration/tokens, last run time/status/result, used plugins and skills |
| Notifications | record (log) / email (SMTP, with file attachments) / session (DSH-IM social-software bridge) |
| Permission management | Per-task permission preset: `workspace-write` or `danger-full-access` (long-term authorization, no approval prompts) |
| Conversation control | 9 `autodsh_*` model tools: create/update/delete/list/detail/run/stop/history/settings |
| Auto-learning | Installs the `autodsh-control` skill so models automatically know how to control the plugin |
| Task panel | Built-in Web panel (list/detail/edit/run/stop/delete/history) with full configuration forms |

## Architecture

```
             ┌──────────────────────────────────────────────┐
  Chat/User ─▶│  autodsh (Host half, resident with DSH)       │
             │                                              │
             │  autodsh_* tools ←→ task store (storage-domain)│
             │       │              ▲                        │
             │       ▼              │ change events          │
             │  trigger engine ──▶ task runner               │
             │  (interval/        (isolated agent session +  │
             │   cron/             workspace, stats)          │
             │   condition/                                  │
             │   parent)            │                        │
             │                      ▼                        │
             │               notifier (log / email / IM)     │
             │       │                                      │
             │  autodsh-control skill (model auto-learning)  │
             └───────┼──────────────────────────────────────┘
                     │ /autodsh/api (webServer routes)
             ┌───────▼──────────────────────────────────────┐
             │ Task panel (Client half, Web settings page)   │
             └──────────────────────────────────────────────┘
```

See [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) for details.

## Installation

### Local development install (recommended first)

```sh
# 1. Build in the project root
pnpm install
pnpm run build

# 2. Install into a target profile (copies artifacts + appends the mount
#    row, backs up the patch automatically)
node scripts/install-local.mjs desktop
# or: node scripts/install-local.mjs web

# 3. Restart DSH
```

Manual approach (when the install script does not apply):

```sh
dsh plugin --profile web add link:
# Add the mount row to the target profile's cordis.patch.yml:
- insert:
    - id: autodsh
      name: 'autodsh'
```

Data lives in `$DSH_HOME/storages/autodsh.json`.

### Install from npm (published on npmjs.com)

The package is published to the official npm registry as `@juuuw/autodsh`.

```sh
# 1. Install from the default npm registry
npm install @juuuw/autodsh

# 2. Add the mount row to the target profile's cordis.patch.yml:
# - insert:
#     - id: autodsh
#       name: '@juuuw/autodsh'
```

> Alternative source: `@juuwaii/autodsh` is also published on the GitHub
> Packages registry (see [README.zh.md](README.zh.md) for registry config).

## Quick Start (conversation)

After installing and restarting, just say:

- "Create an automation task that checks my project dependencies every morning at 9 and summarizes"
- "Fetch a news digest every 2 hours and email it to me"
- "Automatically retry once when my inspection task fails"
- "List all tasks" / "Disable task xxx" / "Run task xxx now"

The model auto-loads the `autodsh-control` skill and uses the `autodsh_*`
tools. You can also manage tasks in **Settings → Autodsh Task Panel**.

## Task Fields (viewable/editable in the panel)

Name, description, enable toggle, trigger (type and parameters), task content
(prompt), key parameters (sensitive ones masked), working directory, agent
preset, **permission preset**, run timeout, notification channels/timing,
email recipients, parent task, run statistics (last run time/duration/status/
result, totals, used plugins/skills), and run history.

The panel's **Edit Config** form supports:
- name / description / task content
- trigger switching (interval interval-ms, or cron expression)
- notification channels (record / email / session) with timing and recipients
- **permission preset** (default / `workspace-write` / `danger-full-access`)

## Permission Management (Long-term Authorization)

Each task can declare a permission preset (`permission` field, also available
in the panel and `autodsh_task_create/update` tools):

| Preset | Sandbox | Approval | Use case |
| --- | --- | --- | --- |
| `workspace-write` | workspace + allowed temp dirs | ask | Default; wider operations require approval |
| `danger-full-access` | full file access | never | Unattended long-running tasks: full permissions, no approval prompts |

The preset is applied to the task agent at run time via `permissionPresets.set`
(sandbox mode + approval policy). Unknown preset names only warn and do not
block the run.

## Notifications

- **record**: appends to `/notifications.log` (JSONL); always available.
- **email**: SMTP mail. Configure `smtp.host/port/secure/user/password/from`
  via the `autodsh_task_settings` tool (or settings), and set `emailTo` on the
  task. A zero-dependency SMTP client (node:net/tls) supports 465 direct TLS,
  587/25 STARTTLS, AUTH LOGIN/PLAIN, UTF-8 base64 bodies, and **file
  attachments** (multipart/mixed; result files under 10 MB are attached
  automatically).
- **session**: injects the result into the session that created the task.
  If that session is bound to a social channel by
  [DSH-IM (@xmanrui/dsh-im)](https://github.com/xmanrui/dsh-im), the result is
  delivered with the next interaction (DSH-IM push is message-driven: only
  replies of user-message turns are pushed; there is no proactive text API,
  and the QQ channel does not implement file messages). For proactive
  delivery use the **email** channel.

## Triggers

- `interval`: fixed period in ms (optional random jitter);
- `schedule`: 5-field cron (`min hour day month dow`, local timezone; day/dow
  combine with standard cron semantics);
- `condition`: last run status / last duration comparison / time window
  (fires once per window);
- `parent`: triggers the child after the parent run ends, on
  `success | failure | completion | always` (with optional delay), and injects
  the parent's result summary into the child prompt.

## Development & Testing

```sh
pnpm install
pnpm run build        # Host (tsc) + Client (tsc + rollup)
pnpm test             # unit tests (node --test)
```

- Test coverage: cron parsing, file storage (atomic updates/capacity/history
  cleanup), trigger engine (all four trigger types), notifier, SMTP client
  (local fake server, incl. multipart attachments), task-runner full-chain
  orchestration, panel API (45 tests).
- Rich code comments; relative imports follow the NodeNext `.js` suffix
  convention.

## Requirements Traceability

See [README.zh.md](README.zh.md) for the full requirement mapping table.

## Privacy & Security

- The committed code contains **no personal information, secrets, tokens, or
  machine paths**; local test data lives under `$DSH_HOME` and gitignored
  directories.
- Task key parameters support the `secret` flag: masked as `******` in the
  panel and model tools.
- SMTP passwords and other sensitive settings are kept in
  `$DSH_HOME/settings.yaml` (DSH defaults to 0600) and are masked on read.
- Plugin data is plaintext local storage; avoid storing high-value
  credentials. Clear sensitive content before sharing/publishing task configs.

## License

[MIT](LICENSE)