` installed the bundle in
~449 ms; `dsh --profile --dump-config` composed the `iterate-plugin` bundle
patch into the profile; `dsh plugin --profile
remove iterate-plugin`
uninstalled in ~602 ms and left zero references in the composed config. A full
runtime boot was **not** exercised here (no model provider in the disposable
profile), so `dshOperations` start/rollback stay `unknown`/`partial` — see
`CHANGELOG.md` for the exact commands and timings.
### Runtime permissions (conservative disclosure)
The plugin runs with the **same process capabilities as the DSH host** and touches the
following capabilities; elevated capability means a DSH Profile install stays
`user-reviewed`/guarded rather than auto-approved:
- **Files** — reads and writes project-local state under `/.iterate/`
(decision log, checkpoint, transcript, fix backups/registry, quality gate,
experience bank, defense events). `iterate_fix` / `iterate_triage` also apply
in-place edits to the user's source files (path-traversal protected to the
resolved project root, backups taken before every fix, rollback on failure).
The client half persists triage verdicts to `localStorage`.
- **Commands** — the plugin's own tools execute a small, strictly bounded command
surface inside the dsh host process, only when the model calls them: `iterate_validate`
runs one of the **exact-match whitelisted** commands configured in
`iterate.config.yaml` `validation.commands` (yes, it shells out via
`node:child_process`, timeout-capped to ≤600 s); `iterate_review` (changed-only
scope) runs `git diff --name-only -z ` in the project root. Nothing else
spawns a process. The client "command buttons" only copy paste-able instruction
text; they do not spawn processes.
- **Credentials** — this plugin does **not** read or transmit credentials at
runtime. The sibling **iterate-skill / iterate-harness** components may read git
credentials / GitHub tokens when the user runs their own Git/API operations; those
are separate packages and are never loaded by this plugin.
- **Network** — no network access at runtime (everything is local to the project).
### Dependencies
Runtime dependencies: `@deepseek-ai/cordis`, `@deepseek-ai/dsh-tools`,
`@deepseek-ai/dsh-util-values`, `js-yaml` — all pinned exact versions. No
install-time lifecycle scripts (`preinstall`/`install`/`postinstall`/`prepare`);
only `prepublishOnly` (build) runs on publish.
### Failure bounds
- All writes are atomic (temp + rename) and confined under `.iterate/`; a crash
mid-write cannot corrupt the checkpoint/transcript.
- Persistence failures surface as structured `{ ok: false, error }` results instead
of silent success.
- Fix edits are applied to backups first and rolled back on validation failure.
- The UI degrades gracefully when a slot/service is unavailable.
---
## 🎨 Design
The plugin follows dsh's "everything-is-a-plugin" architecture:
- **Does exactly two things** — injects the system prompt teaching the model the iterate workflow + registers 17 pure-function tools
- **All orchestration runs through dsh native `workflow` + `agent` + `parallel`**
- **Core logic is entirely pure functions** (dedupe / filter / sort / converge / meta-audit / diff computation / history filtering / cleanup reporting) — unit-testable, no I/O
- **Security model** — file writes confined to the resolved project root (path-traversal protection); always back up before writing, roll back on failure; config writes also back up + roll back; `iterate_prune` is dry-run by default and only clears artifacts under `.iterate/` with every cleanup logged; `iterate_fix` caps content length and `iterate_triage` caps entry count to fend off abnormal oversized payloads
- **Build-free UI** — `lib/client.js` uses a `React.createElement` tree + injected `
