@ddtcorex/dsh-maestro-review
Automated merge-request review for the DeepSeek Harness:
pluggable ReviewProvider (GitLab first), an orchestrator that spins up reviewer/auditor
child agents on fresh worktrees, webhook intake for GitLab events, and a settings/tunnel
client UI injected into the DSH Web slots.
Part of the Maestro Harness suite (dsh-maestro-*). Cordis patch rows:
maestro-review-webhook (intake), maestro-review-orchestrator (pipeline),
maestro-review-settings-rpc (settings UI) — all served by this npm package.
What it provides
- ReviewProvider abstraction — GitLab client today; other forges plug in behind the same
interface.
- Orchestrator — reviewer + auditor agent runs against a disposable worktree of the MR,
model selection overridable globally (
reviewModel) and per project mapping.
- Webhook intake — receives GitLab MR events, enqueues reviews (dedup + retention).
- Review findings/history/signals — findings written through the
review-findings
tool by tool-only review subagents (never free text); history + signals tracked per MR.
- Govard/workspace tooling available inside review runs.
- Client half — settings section rendered into DSH Web slots; notification copy stays
here, delivery goes through the optional
maestroNotifier service.
CI reviewer (no local checkout)
The same pipeline also runs headless from GitLab CI: a shared reviewer
project (holds secrets + image) serves any number of source projects through
a small bridge job — no DSH host, no project mapping needed. Quick runs
diff-only (or on a real checkout when REVIEW_PROFILE is set — reviewer-only,
no auditor); on-demand deep clones the MR head and reviews reviewer-only with
a static-only audit (no govard runtime in the container).
Full setup, per-case trigger workflows (quick/deep × CI/webhook), model
selection, and troubleshooting: docs/ci-reviewer-setup.md.
Templates live in templates/, the image in docker/.
Settings
Reads its configuration through the shared namespaced settings store
(~/.dsh/maestro/settings.json, owned by @ddtcorex/dsh-maestro-config-lib) via the flat
adapter in src/config-store.ts; machine runtime state stays in a package-local sidecar.
Install
dsh plugin --profile web add @ddtcorex/dsh-maestro-review
# or everything at once:
dsh plugin --profile web add @ddtcorex/dsh-maestro-meta
Development
pnpm install
pnpm verify # tsc --noEmit
pnpm test # vitest run
pnpm build # tsc -> lib/
pnpm run build:client # browser bundle -> lib/client.js (required after client changes)
See AGENTS.md for conventions (host/client split, secrets handling, live-validation rules).
Release
A release ships two artifacts that must stay in lockstep: the npm
package and the ddtcorex/maestro-reviewer Docker image — the image
installs the npm package from the registry rather than copying source, so
tagging a release alone is not enough to ship it to CI users. In short:
bump package.json + CHANGELOG.md + the three image-tag references →
tag vX.Y.Z (triggers npm publish + GitHub Release) → bump
profiles/reviewer-ci/package.json's own pin to match → rebuild and push
the Docker image. Full step-by-step checklist, including the pnpm
supply-chain age-gate workaround and how to live-test a fix in the image
before a full release: see Release checklist in AGENTS.md.
License
MIT
