Follow the cordis-plugin-development references instead of the ad-hoc choices
the first version made.
Client half:
- register the row button under this package's own id instead of shadowing the
shipped `archive` action at a lower priority, so the official hover buttons
keep their cells and archiving stays where the harness put it
- drop the synthetic `pointerout` dispatched at a `[data-row-key]` ancestor:
a plugin does not read or drive another package's DOM, so the tooltip is now
positioned from its own button alone
- keep the self-rendered primitives, the `--dsw-*` token-only styling, and the
modal focus/Escape behavior, and document why
Host half:
- resolve a conversation's descendants with `sessionQuery.traceSession()`
instead of listing every stored header and re-deriving `parentSession` edges
- decide liveness from the traced `SessionRecord.live` flag, which removes the
`agents` and `sessions` dependencies from `inject`
- build the orphan-sweep corpus from `sessionQuery.listSessions()`, which
already merges live and persisted sessions
- document that `sessionPersistence.locate()` is a JSONL-backend diagnostic
hook, not part of the seam, and keep probing it explicitly
- record only tree roots in the deferred-deletion ledger: the activation sweep
removes a root with everything under it, so a separately recorded child was
deleted twice or needed a pass that never runs
- return the activation's sweep promise from `apply()` so a test can await it
Manifest and docs:
- version 2.0.0, `private`, `dsh.manifestVersion`, and `engines`
- delete the Gitea npm publish workflow and every npm-publishing task: the
package is distributed only through the Git repository and tags
- rewrite the README around the current install paths and the plugin's limits
The job token belongs to the gitea-actions pseudo user, which is not an organisation member, and Gitea grants package write only to members of the owning organisation; v1.0.2 proved it with E401 on the job token and a successful publish on the PAT. The step now prefers NPM_TOKEN and only falls back to the job token, printing its identity when it does.
The publish step now tries the built-in Gitea job token first, prints which user it belongs to, falls back to NPM_TOKEN when the registry rejects it, and reports which token actually published. A 409 keeps meaning 'already published', so a re-run stays harmless.
The first run failed with E401 while using the built-in token and before the workflow declared permissions, so nothing here proves the job token cannot publish. The header now says a write:package token is what makes publishing reliable, that the job token depends on the instance's Actions token settings, and that permissions: packages: write is what keeps a restricted token from being read-only.
pnpm accepts #semver:^1.0.1 on a git address and resolves it against the repository tags; verified against this repository, where it selected the v1.0.1 commit.
The dialog has two inputs: the spec field takes a package name, a git address or a local path, while the install source only decides which registry a package name is looked up in. Git and tarball specs are fetched directly, so the source can stay on its default; the previous wording left that open and the address ended up in the wrong field.
Gitea's npm registry returns a fixed field set, so the dsh field never reaches the installer's registry preflight and the install is refused with 'declares no dsh.bundle'. The tarball and the git address carry the real package.json, so they are the routes that work.
Only the features, the behaviour boundaries, the three ways to install it, and a precise compatibility statement remain; the release pipeline, the file layout and the local-directory install method are gone. The install section now mirrors how a published DSH plugin is described: npm package plus custom registry, a pinned git URL, or a downloaded tgz.
The publish section now says why the workflow avoids external actions, that a repeated version is a skip rather than a failure, and that an npm registry line pointing elsewhere produces a misleading 'version already exists'.
Without setup-node nothing wrote the default registry, so npm compared versions against registry.npmjs.org and refused with 'cannot publish over the previously published versions'. The step now sets the default registry too, and treats both that message and Gitea's 409 as an idempotent skip.
Runs 11 and 14 died on 'dial tcp 20.205.243.166:443: i/o timeout' while act_runner cloned actions/checkout from GitHub. The workflow now fetches its own ref with git and relies on the node already present in the runner image, so it only touches this instance.
The registry check through npm view did not see the existing version, so publish ran into E409. The registry itself is the authority here: a 409 now reports 'already exists, skipping' and exits zero, while every other error still fails the step.
Gitea does not implement the npm whoami endpoint and npm refuses to read an auth token back, so both lines only produced error-looking output. The run now checks the registry first and skips publishing a version that already exists, which also makes a manual re-run safe.
The first tagged run failed inside the publish step within a second, which is the shape of an auth rejection rather than a build problem. The step now prefers a repository NPM_TOKEN secret when one exists, prints the effective registry and a masked token, and runs npm whoami so a re-run names the cause instead of just failing.
The registry owner is the scope the package must publish under, so the name moves from @local/ to @dsh-plugin/ in all three places that must agree: package.json, cordis.patch.yml, and the client module id. `private` goes away because npm refuses to publish such a package, and publishConfig pins the registry to this organization's npm endpoint.
The tag workflow publishes whatever version the pushed v* tag names, using the built-in Gitea job token, and refuses a tag that disagrees with package.json.
pyh