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.
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