Skip to content

Releases

v0.4.1 — re-verified against DSH 0.2.0-rc.2

Choose a tag to compare

@lijiawei255 lijiawei255 released this 08 Oct 14:16

v0.4.1 — re-verified against DSH 0.2.0-rc.2

No plugin code changed. 0.2.0-rc.2 broke nothing, so this release exists to check that
claim
and then to put the answer where a visitor can see it.

0.4.0 was verified against 0.1.7-rc.2. 0.2.0-rc.2 was published five days later and became
what DSH Desktop ships, and the repository had not been touched since — so every page in it
named a host two generations old, and a reader could not tell whether the plugin worked on the
version they had just installed.

What was re-checked

Interface audit. Every service, event and field name the plugin depends on was looked up by
name in the shipped 0.2.0-rc.2 app.asar (8097 JS files), not in a changelog. Nothing was
removed or renamed.
The only absent hook is jobs.onJobDone, gone since 0.1.7, so the
fallback branch is simply never taken, as designed.

All eight scenes re-triggered on a real 0.2.0-rc.2 host, using the official runtime's own
bundled CLI (dsh headless, --version → 0.2.0-rc.2) against a throwaway DSH_HOME, with
the plugin mounted exactly as the desktop profile mounts it and its player pointed at a stub
play.ps1 that records the clip it was handed instead of making noise.

Scene Result
needs-input ✅ played needs-input.wav
approval ✅ played approval.wav (real approval request, ask policy)
goal-complete ✅ played goal-complete.wav
goal-blocked ✅ played goal-blocked.wav
job-done ✅ played job-done.wav
job-failed ✅ played job-failed.wav — first time this scene has ever been triggered
turn-done ⚠️ correct scene, clip and player process observed; playback stopped 21 ms later because a one-shot host disposes the plugin tree at turn end (a dsh headless property — a desktop host stays up across turns)
turn-error ⚠️ same, on a turn that genuinely ended error

job-failed fired on the path the old record predicted: a background tool task that failed
settled with terminal status failed. The same job under danger-full-access completed and
spoke job-done instead — the discrimination the scene exists for. The older half is unchanged
and still documented: a background shell command that runs and exits non-zero still settles
completed.

Also in this release

  • A DSH version badge and a compatibility statement at the top of both READMEs, plus a
    version requirement in each install section. Before this, the only version statement in the
    repository lived in the middle of the verification table, and it named 0.1.7-rc.2.
  • The repository description now carries the version.
  • Fixed a stale log path in both READMEs. They pointed at
    %APPDATA%\DSH Desktop\logs\host\dsh-<date>.log — the discontinued third-party shell; there
    is no %APPDATA%\DSH Desktop directory on the official build. Re-measured on 0.2.0-rc.2:
    logs/host is absent from the asar (0 hits) and the official userData logs/ directory is
    empty.
  • CI's pinned DSH moved from 0.1.7-rc.2 to 0.2.0-rc.2, and its now-wrong comment (it
    still claimed npm's latest was 0.1.5-rc.3) was rewritten.
  • Full method, evidence and the two things this pass did not establish are in
    docs/verification.md §0.

Suites

selftest.mjs 76/76 · qa-negative-control.mjs 10/10 · verify-local-install.mjs 10/10 ·
sync-profile.mjs --check → PARITY after --apply.

Install / upgrade

dsh plugin --profile <PROFILE> add -w github:lijiawei255/dsh-status-chime

Then fully restart DSH Desktop — plugin code is not hot-loaded. Existing installs need no
config change: 0.4.0 and 0.4.1 behave identically.

Try the audio without installing

The 16 .mp3 files below are audition copies, not install artifacts — every install ships
all 32 files (16 lines × mp3 + wav) inside the package. Files without a suffix are Chinese (the
default set); .en files are English.

v0.4.0 — background-job alerts restored on DSH 0.1.7

Choose a tag to compare

@lijiawei255 lijiawei255 released this 25 Sep 07:13

Background-job alerts work again on DSH 0.1.7

DSH 0.1.7 removed jobs.onJobDone, which was the only background-job API 0.3.0 knew. On
0.1.7 that left the job-done and job-failed scenes dead, with no error logged: the
exception is thrown inside an ctx.inject callback, and cordis contains a failing plugin per
fiber, so nothing surfaced.

This release subscribes to 0.1.7's ctx.jobs.events.subscribe({ owners: 'all' }) commit stream
and reads settled. The old callback is kept as a fallback, taken only when the stream is
absent, so DSH 0.1.5 and 0.1.6 keep working too. Which branch is in use is logged at load
time; if neither exists the plugin warns once and keeps its other scenes.

Two of settled's fields suppress the alert, matching what the host's own job reporter does:
awaited (a waiting caller already collected the result) and cause: 'teardown' (the session
was archived, or the host is exiting). Without them, every shutdown would speak and every
job_wait would double-report.

Verified on the real thing, not only in the suite: a background job started and deliberately
never waited on played the clip when it settled, on @deepseek-ai/dsh 0.1.7-rc.2.

Also in this release

  • scripts/sync-profile.mjs makes "the local single-file install matches this repository"
    a checkable claim: it mirrors the plugin file and the audio assets by hash, and compares the
    published assets/clips.json against the private master by printing differing field paths
    only, requiring every functional path to be identical. Measured on the current pair: 50 paths
    differ, 0 of them functional — the machine-checkable form of "the clips were not
    regenerated for publication".
  • scripts/verify-local-install.mjs was skipping both of its isolation checks on the
    install it exists for: the skip condition tested for the Scene-line marker (missing) inside
    the Clip-sets line, whose own wording is missing, so the branch could never be taken. It now
    probes <plugin dir>/../assets/clips. The installed copy goes from 8/8 with 2 skipped to
    10/10.
  • Two README passages quoted a model's audition review verbatim and carried wording this project
    does not publish. The assessment is unchanged — which candidate won, and on what grounds — only
    the register is now neutral. No audio was regenerated, and the mirror check asserts that.
  • New docs/mirror-policy.md
    states what is byte-identical between this repository and the author's local install, what is
    deliberately sanitised, and how the wording gate works.
  • The offline suite grows from 63 to 76 checks; the verification baseline moves to
    @deepseek-ai/dsh 0.1.7-rc.2, with CI's pin following it.

Install

dsh plugin --profile <PROFILE> add -w github:lijiawei255/dsh-status-chime

Then fully quit and reopen DeepSeek Harness — plugin code is not hot-loaded. Run
/voice-alerts status and you should see Voice alerts: on (v0.4.0).

The audio attachments

The 16 *.mp3 files below are for listening only, not an install artifact — the package
already ships all 32 files (16 clips × mp3 + wav). Bare names are the Chinese set (the default);
.en names are English. They are unchanged since 0.3.0: this release changed code only.

v0.3.0 — two languages, the approval scene, and a command that takes arguments

Choose a tag to compare

@lijiawei255 lijiawei255 released this 21 Sep 05:02

dsh-status-chime 0.3.0

Spoken status alerts for DeepSeek Harness. This is the first release with two languages
and with the eighth scene, approval.

Audio samples (for listening only)

The 16 .mp3 files below are the shipped clips, attached so you can hear them without
installing anything — GitHub renders no audio player in Markdown.

  • Chinese is the default, so the bare names are Chinese: turn-done.mp3, turn-error.mp3, …
  • The English set carries the language suffix: turn-done.en.mp3, turn-error.en.mp3, …

These are not an install artifact. Install with dsh plugin add (see INSTALL.md); the
package ships the clips itself, in both .mp3 and .wav, so nothing needs downloading here.

What is in this release

  • Eight scenes: turn done, turn error, job done, job failed, goal complete, goal blocked,
    an approval waiting, and the agent waiting for your answer.
  • Chinese and English audio, switched at runtime with /voice-alerts lang en. Chinese is
    the default; an unrecognised value falls back to Chinese rather than going silent.
  • Playback happens in the host process — through ffplay when it is present, otherwise
    through the Windows PowerShell player that ships with the OS. No third-party runtime
    dependency, and deliberately not a Web Audio tab, so an alert does not depend on a browser
    tab being open.
  • The command accepts arguments. An input hint is declared, which is what lets DSH's
    command UI pass the rest of the line through — without it, on, off, status,
    test <scene> and lang <zh|en> could not be typed at all, only the bare preview.
  • An interrupted clip is no longer replayed. Killing the clip that is playing is how a
    higher-priority alert cuts in. A process killed on purpose reports no exit code, which the
    play.ps1 retry handler read as a failed script — so it answered by replaying the very
    clip that had just been cut off, and the two could overlap. Children the plugin kills are
    now recorded and skipped. (The same path replayed a clip on unload.)
  • The offline suite is up to 63 checks, and the playback log now names the file, the
    backend, the resolution level and (for ffplay) the volume it was handed — enough to answer
    "which copy actually played, and did the configured volume reach it?" from the log alone.
    The plugin also logs when it releases the player on unload, so a clean shutdown is
    observable rather than assumed.

Known limitations

  • Windows only (os: ["win32"]).
  • job-failed cannot fire for a background shell command that exits non-zero. The job
    snapshot carries no exit code and the shell producer only emits completed or killed.
    DSH's own desktop notifications share that blind spot, so it is framework behaviour.
  • The English set is verified by measurement, not by ear. ASR read-back is 1.000 on all
    eight (re-measured with the correct --lang en), plus peak/mean silence floors and UTMOS —
    but it has not had a human listening pass, while the Chinese eight have.
  • Which approval path delivered the alert is unresolved. The approval/asked session
    event and the approval/request waterfall play the same clip, so hearing it does not
    distinguish them.
  • Regenerating the audio needs an Alibaba Cloud Bailian key and ffmpeg. Installing and
    using the plugin needs neither.

docs/verification.md records what was measured and, just as deliberately, what was not.

v0.1.0 — first release (superseded, old package name)

Choose a tag to compare

@lijiawei255 lijiawei255 released this 20 Sep 20:54

dsh-voice-alerts 0.1.0 — superseded

This is the first public release, from before the project was renamed. The package is
now dsh-status-chime; only the package and repository names changed, so the cordis id,
the /voice-alerts command and the config/clip paths are all still voice-alerts.

Its audio attachments are out of date and should not be used for listening:

  • they are 7 clips, Chinese only — the eighth scene (approval) and the entire English
    set did not exist yet;
  • the current set is 16 clips (8 scenes × 2 languages).

Use the latest release
instead.
The files here are kept only so this release's history stays intact.