Repository navigation
Releases: tcgbp/dsh-flash-ctx-mon
Release list
dsh-flash-ctx-mon 0.1.8 — the skills chip moves to the session tab strip
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.actionsas
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
MutationObserverre-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
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.injectnow namesdsh-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-flashcore.
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
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
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
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
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.