dsh-ai-terminal-pet 1.2.4 → 1.2.6

package/README.md

@@ -19,42 +19,50 @@ maintainer pins a release in lib/release-pins.json, see below).
 
 ## What it does
 
-| Harness event | Overlay state |
+| Harness signal | Overlay state |
 | --- | --- |
-| turn/start, agent/inbox/claimed, agent/status running | working |
-| tool/call | tool_use |
-| approval/asked, approval/request | waiting_permission |
-| tool/result with error, command/done error, agent/error | error |
-| turn/end, command/done success | idle |
+| `turn/start`, `agent/inbox/claimed`, `agent/status` running | working |
+| `tool/call` | tool_use |
+| `approval/request` (waterfall listener) | waiting_permission |
+| `tool/result` with `error`, `agent/error` | error |
+| `turn/end`, `agent/status` idle | idle |
 | Harness process exit | closed |
 
+Events this table does not list are not part of the Harness session log: there is
+no `command/done` or `working-directory/change` in `SessionEventMap`. The project
+path, the parent session and the session start time do not come from events at
+all - they are read from `session.header` (`cwd`, `parentSession`, `createdAt`),
+which is the only place the host states them. That is also why a session shows
+the right project even though the desktop Harness itself runs from its install
+directory, and why a subagent conversation is nested under the session it was
+forked from.
+
 The overlay then plays an alert tone, shows a tray balloon on those transitions
 and its one-click jump button targets the Harness window. Plugin reload (HMR)
 disposes the listeners but deliberately does not close sessions: only a real
 process exit means the conversation is over.
 
-The bundle's entry in the [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)
-registry ([PR #13937](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/13937)) was
-merged on 2026-11-10, and that repository's README lists it. Being merged is not the same as
-being visible in a market, and initially it was not: the entry page answered 404 and the catalog
-file behind DSH's own Plugins -> Market did not contain this repository while the upstream site
-build was still queued. That build finished (run 42844452013, 16:39:27Z), the entry page now
-answers 200, and the catalog (`count` 10119 -> 10230) lists this repository - so it can be found
-in that market. The entry's `install` command, however, is generated from the pinned `tarball`
-and pointed at the 1.2.0 asset; a follow-up PR moves it to the current release, which is 1.2.4.
-Changing that file always means a pull request against that repository, never an edit here.
-
-The other route needs no application at all: third-party markets harvest GitHub
-repositories carrying the `dsh-plugin` topic (this repository has it) together with
-a root `package.json` that declares `name` and `dsh.bundle`. That is exactly why
-the repository root carries a shim manifest — `dsh plugin add github:owner/repo`
-reads the root manifest, and without one the install resolves to a 0.0.0
-dependency that mounts nothing.
-
-The package describes itself to those storefronts through `dsh.catalog`: a
-category, a one-line summary in both languages, and the capabilities it uses.
-Capabilities are self-declared and never checked — DSH does not sandbox plugins —
-so read them as a description, not a permission grant.
+## Where it is listed, and what each market indexes
+
+Three independent paths exist today, and each one reads a different field:
+
+| Market | What it indexes | What this package offers it |
+| --- | --- | --- |
+| npm registry | package name, version, `dist.integrity` | published as `dsh-ai-terminal-pet`; a market that installs by name gets a verified tarball |
+| dshmarket (the market tab most Harness Desktop users run) | `https://awesome-dsh-plugin.com/plugins.json`, which is generated from the [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) repository | entry merged via PR [#13937](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/13937); the `install` command it renders comes from that entry's pinned `tarball`, so bumping it is always a pull request *there*, never an edit here |
+| GitHub-harvesting markets | repositories carrying the `dsh-plugin` topic plus a root `package.json` declaring `name` and `dsh.bundle` | this repository has the topic and the root shim manifest, which is what makes `dsh plugin add github:owner/repo` resolve instead of mounting a 0.0.0 dependency |
+
+"Listed" and "visible" are different states, and only the second one helps a
+user: the awesome entry existed before its `plugins.json` entry did, because the
+site builds the catalog on a schedule. Check the market's own public index, not
+the merged pull request. The package README cannot promise what another
+repository's build will render; it can only promise that the fields those builds
+read are present and correct.
+
+The package describes itself to storefronts through `dsh.catalog`: a category, a
+one-line summary in both languages, and the capabilities it uses. Capabilities
+are self-declared and never checked — DSH does not sandbox plugins — so read them
+as a description, not a permission grant.
 The bundle is Windows only and declares `dsh.bundle.platforms: ["win32"]`, so
 other platforms show it as unsupported instead of installing it.
 
@@ -64,17 +72,26 @@ that field - the bundle mounts through `dsh.bundle` either way - but storefronts
 that sort entries by profile do: without it a registry falls back to a
 headless-or-web guess and a desktop client hides the entry.
 
-Manually, from a terminal, into a profile you own — use the release tarball or
-pin the release tag. Both are verified end to end:
+Manually, from a terminal, into a profile you own — by package name, by release
+tarball, or by pinning the release tag. All three are verified end to end:
 
 ```sh
-# release tarball: no clone, no Go toolchain
-dsh plugin --profile <profile> add https://github.com/jjjjjjjjnnjnn/ai-terminal-pet/releases/download/dsh-plugin-v1.2.4/dsh-ai-terminal-pet-1.2.4.tgz
+# by package name: published on npm, no clone, no Go toolchain
+dsh plugin --profile <profile> add dsh-ai-terminal-pet
+
+# release tarball: same bytes as the npm release, straight from the GitHub Release
+dsh plugin --profile <profile> add https://github.com/jjjjjjjjnnjnn/ai-terminal-pet/releases/download/dsh-plugin-v1.2.6/dsh-ai-terminal-pet-1.2.6.tgz
 
 # git source, pinned to the release tag
-dsh plugin --profile <profile> add "git+https://github.com/jjjjjjjjnnjnn/ai-terminal-pet.git#dsh-plugin-v1.2.4&path:/packages/dsh-ai-terminal-pet"
+dsh plugin --profile <profile> add "git+https://github.com/jjjjjjjjnnjnn/ai-terminal-pet.git#dsh-plugin-v1.2.6&path:/packages/dsh-ai-terminal-pet"
 ```
 
+Those three differ only in transport. The npm path is the shortest and the one a
+market uses when it installs by name; the tarball path works when a market pins a
+release asset instead of a registry entry; the git path is the fallback for a
+machine that cannot reach npm at all. Every one of them lands the same
+prebuilt overlay in `vendor/`.
+
 Do not hand pnpm a bare repository URL. pnpm resolves a git dependency by
 running the package's lifecycle scripts, and it blocks those for unpinned
 git sources until you copy the `allowBuilds` key it prints into your profile's
@@ -85,9 +102,12 @@ SHA-256 of that file, the SHA-256 of the Go sources it was built from, and the
 Go version that produced it, so a stale or hand-edited vendor directory fails a
 check instead of shipping quietly.
 
-The GitHub paths above need no npm. Installing by package name
-(`add dsh-ai-terminal-pet`) starts working once the package is published to the
-npm registry; until then use one of the two commands above.
+The GitHub and npm paths above need nothing from this repository at install time.
+`dsh plugin add dsh-ai-terminal-pet` resolves through the npm registry; the
+tarball and git forms resolve through GitHub. A marketplace that indexes npm
+sees the package under its own name and can verify the published integrity
+digest; a marketplace that indexes repositories sees the `dsh-plugin` topic and
+the root shim manifest.
 
 `add` is the whole install: the profile records the dependency, and the bundle
 declares itself through `dsh.bundle.patch`, so no separate `enable` step exists.

package/lib/index.js

@@ -125,20 +125,51 @@ function officialProtocol() {
 /** Per-conversation state. Kept at module scope so plugin HMR does not lose it. */
 const sessions = new Map()
 
-function metaFor(sessionId) {
+/**
+ * The session header, whichever shape the caller was handed.
+ *
+ * `session/event` hands over the session object itself; other events hand over
+ * a wrapper with `.agent`. The header is the only place the Harness states a
+ * session's cwd, lineage and creation time, so everything below reads it from
+ * here instead of guessing.
+ */
+function headerOf(candidate) {
+  return candidate?.session?.header ?? candidate?.header ?? candidate?.agent?.session?.header ?? null
+}
+
+/** What the header says about one candidate, with safe fallbacks. */
+function sessionInfo(candidate) {
+  const header = headerOf(candidate)
+  const cwd = header && typeof header.cwd === 'string' ? header.cwd : ''
+  const parent = header && header.parentSession != null ? String(header.parentSession) : ''
+  const createdAt = header && Number.isFinite(header.createdAt) ? header.createdAt : 0
+  return { id: sessionIdOf(candidate), cwd, parent, createdAt }
+}
+
+function metaFor(sessionId, info) {
   let item = sessions.get(sessionId)
   if (!item) {
     item = {
       state: 'idle',
-      project: safeCwd(),
+      // The session's own cwd, never the host process's: a desktop Harness runs
+      // from its install directory, so process.cwd() would label every session
+      // with the same wrong path.
+      project: info?.cwd || safeCwd(),
       title: TITLE,
       tool: '',
       reason: '',
-      startedAt: new Date().toISOString(),
+      parentSessionId: info?.parent || '',
+      startedAt: new Date(info?.createdAt || Date.now()).toISOString(),
       stateAt: 0,
       sentAt: 0,
     }
     sessions.set(sessionId, item)
+  } else if (info) {
+    // The header is authoritative for a session that has not stated a project
+    // yet. An explicit project from an event wins for that report, which is
+    // what keeps a future cwd-change extension working.
+    if (!item.project && info.cwd) item.project = info.cwd
+    if (info.parent) item.parentSessionId = info.parent
   }
   return item
 }
@@ -166,25 +197,47 @@ function sessionIdOf(...candidates) {
   return 'dsh-main'
 }
 
+/**
+ * What makes one report different from the previous one.
+ *
+ * The state alone is not enough: a patch can move the project, the reason, the
+ * tool or the lineage without touching the state, and the panel shows all of
+ * them. De-duplicating on state alone silently dropped those updates. Identical
+ * repeats are still dropped, which is what keeps a tool that fires fifty events
+ * per second from flooding the pipe.
+ */
+function signatureOf(item) {
+  return [
+    item.state,
+    item.reason || '',
+    item.tool || '',
+    item.project || '',
+    item.title || '',
+    item.parentSessionId || '',
+  ].join('\u0000')
+}
+
 /**
  * Publish one status. The protocol module writes the durable snapshot
  * synchronously before its first await, so calling this from process.on('exit')
  * still leaves a correct closed-state snapshot even when the pipe is gone.
  */
-function report(sessionId, patch, force = false) {
+function report(sessionId, patch, force = false, info = null) {
   const p = officialProtocol()
   if (!p || typeof p.sendStatus !== 'function') return
-  const item = metaFor(sessionId)
-  const previous = item.state
+  const item = metaFor(sessionId, info)
+  const previousState = item.state
+  const previousSignature = signatureOf(item)
   Object.assign(item, patch)
   if (!p.STATES.has(item.state)) item.state = 'idle'
 
   const now = Date.now()
-  const changed = item.state !== previous
+  const changed = signatureOf(item) !== previousSignature
+  const stateChanged = item.state !== previousState
   const stale = now - item.sentAt >= KEEP_ALIVE_MS
   if (!force && !changed && !stale) return
   item.sentAt = now
-  if (changed) item.stateAt = now
+  if (stateChanged) item.stateAt = now
 
   const stablePid = typeof p.stableProcessId === 'function'
     ? p.stableProcessId(SOURCE + ':' + sessionId)
@@ -194,7 +247,7 @@ function report(sessionId, patch, force = false) {
     schemaVersion: p.SCHEMA_VERSION,
     source: SOURCE,
     sessionId,
-    parentSessionId: '',
+    parentSessionId: item.parentSessionId || '',
     // Synthetic per-conversation pid (never used for OS liveness) plus the
     // real Harness host pid as the ancestor-chain anchor.
     pid: stablePid,
@@ -219,6 +272,17 @@ function report(sessionId, patch, force = false) {
   }
 }
 
+/**
+ * Report for whatever object an event handler was given, after folding in what
+ * its session header says. Every handler goes through here so the project path
+ * and the parent link are never taken from the host process or invented per
+ * event type.
+ */
+function reportFor(candidate, patch, force = false) {
+  const info = sessionInfo(candidate)
+  return report(info.id, patch, force, info)
+}
+
 /** Copy one file into place through a temp sibling, never replacing a file. */
 function copyVerified(source, destination, mode) {
   let temp = ''
@@ -436,7 +500,24 @@ function bootstrap(ctx) {
   return bootstrapPromise
 }
 
-/** Map the durable session events documented in Harness' SessionEventMap. */
+/**
+ * Map one durable session event onto a state patch.
+ *
+ * The authoritative list lives in @deepseek-ai/dsh-session's SessionEventMap
+ * (`turn/start`, `turn/end`, `step/start`, `step/end`, `user/message`,
+ * `assistant/chunk`, `assistant/message`, `tool/call`, `tool/result`,
+ * `todo/write`, `request/header`, `request/context`, `session/end-seed`), which
+ * this switch covers for every event that says something about activity.
+ *
+ * `working-directory/change` and `session/title` are NOT in that map: the first
+ * does not exist anywhere in the host, the second is a client-side event. Both
+ * branches are kept as cheap forward-compatibility - if a future version emits
+ * them, they map correctly - but the project path and the lineage come from
+ * session.header (see reportFor), which is the only place the host states them.
+ * `approval/asked` / `approval/decided` likewise come from the approval service
+ * rather than the session log; the approval/request waterfall listener in
+ * apply() is the path that actually fires.
+ */
 function eventPatch(type, data) {
   switch (type) {
     case 'approval/asked':
@@ -496,26 +577,25 @@ export function apply(ctx, config) {
     }
 
     on('session/event', (session, event) => {
-      const sessionId = sessionIdOf(session)
       const patch = eventPatch(event?.type, event?.data)
-      if (patch) report(sessionId, patch)
+      if (patch) reportFor(session, patch)
     })
 
     on('agent/inbox/claimed', (payload) => {
-      report(sessionIdOf(payload?.agent), { state: 'working', reason: '', tool: '' })
+      reportFor(payload?.agent, { state: 'working', reason: '', tool: '' })
     })
 
     on('agent/status', (payload) => {
       const status = String(payload?.status ?? '').toLowerCase()
       if (/run|work|busy|think|stream/.test(status)) {
-        report(sessionIdOf(payload?.agent), { state: 'working' })
+        reportFor(payload?.agent, { state: 'working' })
       } else if (/idle|done|wait|stop/.test(status)) {
-        report(sessionIdOf(payload?.agent), { state: 'idle' })
+        reportFor(payload?.agent, { state: 'idle' })
       }
     })
 
     on('agent/error', (payload) => {
-      report(sessionIdOf(payload?.agent), {
+      reportFor(payload?.agent, {
         state: 'error',
         reason: short(payload?.error?.message ?? payload?.error, 120),
       })
@@ -524,7 +604,7 @@ export function apply(ctx, config) {
     // approval/request is a waterfall listener: it must always call next(),
     // otherwise other plugins' approval handling is silently dropped.
     on('approval/request', (request, next) => {
-      report(sessionIdOf(request?.agent), {
+      reportFor(request?.agent, {
         state: 'waiting_permission',
         reason: 'permission required',
         tool: short(request?.toolName, 120),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-ai-terminal-pet",
-  "version": "1.2.4",
+  "version": "1.2.6",
   "description": "DeepSeek Harness Cordis bundle that mirrors session state into the AI Terminal Pet desktop overlay (Windows).",
   "license": "MIT",
   "type": "module",

package/vendor/manifest.json

@@ -3,13 +3,13 @@
   "generatedBy": "scripts/vendor.mjs",
   "goVersion": "go1.27.0",
   "source": {
-    "files": 25,
-    "sha256": "cf647af1aa1f45d1ed6f0df7b97e7e1439272f87064009e1989f1bfbd63db29a"
+    "files": 24,
+    "sha256": "6e2a4511fa4a77c15160a3cb861d77eaff30982d9a6dcafb0b11cb025a5dd454"
   },
   "overlay": {
     "file": "vendor/AI-Terminal-Pet.exe",
     "bytes": 4371968,
-    "sha256": "bbb5163c296cd460d7c9a4c85e10342e125c0bd8017a065f913aa01567d41f0a"
+    "sha256": "cd9011ddf98ebb051d2ccd568913bba89525e6d067e9306bb22a85a8951504ef"
   },
   "protocol": {
     "file": "vendor/protocol.js",

package/vendor/package.json

@@ -0,0 +1 @@
+{ "type": "commonjs" }