Skip to content

Releases: tcgbp/dsh-flash-ctx-mon

dsh-flash-ctx-mon 0.1.8 — the skills chip moves to the session tab strip

Choose a tag to compare

@tcgbp tcgbp released this 08 Oct 15:54

dsh-flash-ctx-mon 0.1.8 — the skills chip moves to the session tab strip

The skills chip used to sit in the session title bar, whose contents change
constantly, so a chip living there shifted around while you read it. It is drawn
on the session's tab strip now, directly after the last conversation tab,
separated from it by the strip's own gap plus 12px so it reads as a status pill
rather than one more tab.

The strip carries no session id — DSH sets data-conversation-session on the
conversation body only — so the slot-registered header chip is what keeps the
chip per-session:

  • it stays registered into conversation.session.header.actions as
    dsh-flash-ctx-mon-skills (order 15) and renders a hidden anchor carrying the
    id the slot handed it;
  • from that anchor it walks up to the nearest ancestor holding exactly one tab
    strip and mounts the visible chip there;
  • an ancestor holding more than one strip means another session is involved, and
    the chip stays in the header; a session with a single conversation view has no
    strip at all, so the header chip remains where it always was;
  • a MutationObserver re-places the chip when a strip is rebuilt or another tab
    appears.

No settings field, switch, route or id changed; the host half is untouched.
Clicking the chip still opens the same context-monitor panel.

Tarball: dsh-flash-ctx-mon.tgz (this release), matching docs/tcgbp__dsh-flash-ctx-mon.yml.

dsh-flash-ctx-mon 0.1.7

Choose a tag to compare

@tcgbp tcgbp released this 08 Oct 14:29

dsh-flash-ctx-mon 0.1.7 — follows the panel core to dsh-flash

The host panel moved out of the retired single package dock-flash@2.x into the
dsh-flash core package, and the dock-base Workbench integration into the
dock-flash@3.0.0 adapter. This release re-points the host contract:

  • dsh.client.inject now names dsh-flash — a client module graph row's id is its package name, so this is what makes the core's client half load first.
  • the peer dependency is now dsh-flash: >=1.0.0-0 <2.0.0-0.
  • the READMEs and the market entry name the dsh-flash core.

Unchanged on purpose: the dock-flash:* switch ids, the dock-flash settings
namespace (the profile entry id deliberately stayed dock-flash), the
quickControl service and the /plugins/dock-flash/… routes.

This is the context monitor: conversation/context pressure tracking surfaced through the panel.

Tarball: dsh-flash-ctx-mon.tgz (this release), matching docs/tcgbp__dsh-flash-ctx-mon.yml.

v0.1.6

Choose a tag to compare

@tcgbp tcgbp released this 06 Oct 15:30

Publishes the corrected repository/homepage metadata and the README install command (now dsh plugin --profile <p> add dsh-flash-ctx-mon). The dsh-market registry resolves the npm mapping from the PUBLISHED package's own repository, so this release is what makes the listing resolvable.

v0.1.5

Choose a tag to compare

@tcgbp tcgbp released this 06 Oct 14:11

The README the manifest already promised.

files listed README.md and README.zh-CN.md, but neither file existed — and pnpm skips a
listed-but-absent path in silence, so every tarball this package produced shipped without any
documentation at all. Both languages are here now, with the same structure, and the tarball
carries 7 files instead of 5.

Written from the code rather than from the dock-flash text it was extracted from, so three
things the extraction changed are stated correctly: the monitor is on by default (absence
of the browser key means on), the host half has no collector and no route (it exists only
to hold the settings namespace), and the model-window auto-fill is a documented no-op — the
built-in table is retired, so the user map is the only real source of a window size.

This release is the READMEs only. The peer-range widening from the previous release is
unchanged, and no switch, field, route or id was added, renamed or removed.

v0.1.4

Choose a tag to compare

@tcgbp tcgbp released this 06 Oct 13:48

The dock-flash peer range excluded the entire 2.x line, so npm refused to install this
package next to dock-flash@2.0.2.
Measured with the packed tarballs — exactly what the
registry serves:

npm error code ERESOLVE
npm error Found: dock-flash@2.0.2
npm error Could not resolve dependency:
npm error peer dock-flash@">=1.5.0-0 <2.0.0-0" from dsh-flash-ctx-mon@0.1.3

The range now carries one branch per tuple whose prereleases must resolve, which is the form
this family states:

">=1.5.0-0 <2.0.0-0 || >=2.0.0-0 <3.0.0-0"

A single >=1.5.0-0 <3.0.0-0 looks equivalent and is not: semver only lets a prerelease satisfy a
comparator set whose matching tuple also carries one, so that spelling rejects 2.0.0-rc.1
(measured with npm's own bundled semver) — which is why the first attempt at this fix was
thrown away.

Both directions are asserted: 2.0.2, 2.0.1 and 2.0.0-rc.1 resolve; 3.0.0-0 and 3.0.0
do not; and the 1.5.0 floor still keeps 1.4.9 out. Then verified for real by installing
the packed tarball beside dock-flash@2.0.2 — no ERESOLVE.

This release carries the peer fix only; the settings.describe() crash fix and the non-fatal
apply() guard are in 0.1.3.

v0.1.3

Choose a tag to compare

@tcgbp tcgbp released this 06 Oct 13:21

settings.describe() is not always a promise — and that took the whole plugin out.

settings.describe() was called with .then(...) unconditionally, but that one name has
two implementations: the typert WIRE form returns a Promise, while the DIRECT form —
SettingsController.describe() in @deepseek-ai/dsh-api-settings-controller — is
synchronous and returns the view object itself, and can throw instead
(settings service is absent: mount @deepseek-ai/dsh-settings).

The resulting TypeError: settings.describe(...).then is not a function is raised
synchronously, so it escaped before the .catch at the end of the loader's chain.

This plugin's apply() is async with no internal try/catch, so the throw rejected apply — and a
failed apply fails the Cordis fiber: the plugin never activates and its switch silently never
appears. That is the reported "the plugin was registered and then silently disappeared".

Both call sites now normalize through _describeAsync(), which accepts a Promise, a plain view, or a
throw, so the loader's existing .catch handles it instead of the plugin dying.

Hardening, in the same release. apply() had no internal try/catch, so any throw inside it
rejected the async apply — and a failed apply fails the Cordis fiber: the plugin never activates
and its switch silently never appears. The body is unchanged and now lives in _applyInner; the public
apply reports the failure (apply failed (non-fatal)) and returns, exactly as dock-flash's has always
done.

Patch: no published surface changed.