@fadhelhaidar/pi-ask-user 1.0.1 → 1.0.3

package/README.md

@@ -30,20 +30,16 @@ This repository therefore owns its releases independently. The config helper and
 ## Install
 
 ```sh
-pi install git:github.com/FadhelHaidar/pi-ask-user@v1.0.1
+pi install npm:@fadhelhaidar/pi-ask-user
 ```
 
-Starting with v1.0.1, Git releases include prebuilt JavaScript and translations in `dist/`. Installation uses these files directly: no Bun, compiler, development dependencies, or local build is required. Pi and its runtime dependencies are still required.
+The npm package and Git releases include prebuilt JavaScript and translations in `dist/`. Installation uses these files directly: no Bun, compiler, development dependencies, or local build is required. Pi and its runtime dependencies are still required.
 
 Restart Pi after installing. Remove any other package registering `ask_user_question` to avoid duplicate registration.
 
 ### GitSync and new machines
 
-Sync the Pi package declaration `git:github.com/FadhelHaidar/pi-ask-user@v1.0.1`, then install the declared package on the destination machine using Pi. If you sync a local checkout instead, include the tracked `dist/` directory and install it with `pi install /path/to/pi-ask-user`. Neither route needs `bun run build` on the destination.
-
-Pinned tags do not automatically advance. A machine still configured for `@v1.0.0` keeps the old package until you change the declaration to a prebuilt release tag. A tag must be published before the corresponding install command works; source changes alone do not create a release.
-
-Each new GitHub release also provides an npm-format `.tgz` containing the same prebuilt runtime. This does not publish the package to npm; the supported Pi installation route remains Git.
+For GitSync and new machines, use the unpinned Pi package source `npm:@fadhelhaidar/pi-ask-user`. Pi can compare npm versions and notify about updates; `pi update --extensions` installs the latest published version. GitHub releases also provide versioned and stable `.tgz` assets for direct installation, but pinned Git tags do not advance automatically. If you sync a local checkout instead, include the tracked `dist/` directory and install it with `pi install /path/to/pi-ask-user`.
 
 ## Preserved custom behavior
 
@@ -99,13 +95,17 @@ Tests and fixtures live in this repository, including the multi-select/custom-an
 
 ### Preparing a release
 
-1. Set `package.json` to the new release version and commit the source and manifest changes. Local build/test and `npm pack --dry-run --ignore-scripts` checks are optional validation.
-2. After review, push or merge the changes to `main` and wait for its Tests workflow, including `publish-dist`, to succeed. If `dist/` changed, wait for the automatic build commit to appear on `main`; if it did not change, no extra commit is needed.
-3. Fetch the updated `main` and inspect the commit you will tag. Only then create and push a matching `v<version>` tag (for this change, `v1.0.1`) on that fresh, prebuilt commit. Do not tag the earlier source-only commit or move an existing release tag.
+Use Conventional Commit messages for changes merged to `main`; Release Please opens or updates a Release PR with the proposed version and changelog:
+
+- `fix: ...` creates a patch release.
+- `feat: ...` creates a minor release.
+- A breaking change (for example, a `BREAKING CHANGE:` footer) creates a major release.
+
+The Release PR is the human approval gate. Review and merge it to approve the version/changelog update; do not manually edit the version or auto-merge this PR. When the merge creates a GitHub release, automation explicitly dispatches the existing release workflow for its generated tag. That workflow validates and publishes the checked-in prebuilt files.
 
-Tag pushes do not run the branch build/publish workflow. They validate the checked-in prebuilt runtime rather than silently rebuilding a release.
+Manual matching `v<version>` tag pushes and `workflow_dispatch` with `release_tag` remain available for recovery. Tag pushes still validate the checked-in prebuilt runtime rather than silently rebuilding a release.
 
-The release workflow rejects tags that do not match `package.json`, checks build freshness, runs tests, packs the prebuilt files, and attaches both a versioned tarball and the stable `pi-ask-user.tgz` asset to each GitHub release. The stable URL `/releases/latest/download/pi-ask-user.tgz` lets Pi update to the newest published release without changing the package declaration. It uses the repository's GitHub token, not npm credentials. A GitHub Actions release run is required to produce the downloadable assets.
+The release workflow rejects tags that do not match `package.json`, checks build freshness, runs tests, and packs the prebuilt files. It attaches both a versioned tarball and the stable `pi-ask-user.tgz` asset to the GitHub release, then publishes the same package to npm from a separate least-privilege job using npm Trusted Publishing (GitHub OIDC; no long-lived npm token). The npm CLI is pinned to 11.5.1 for OIDC support. Configure the package's npm Trusted Publisher for GitHub owner `FadhelHaidar`, repository `pi-ask-user`, and workflow `release.yml`; allow `npm publish`. The stable GitHub URL `/releases/latest/download/pi-ask-user.tgz` remains available for direct installs.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fadhelhaidar/pi-ask-user",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "Standalone Pi questionnaire with combined multi-select and custom answers, Enter-only toggling, and preserved drafts.",
   "type": "module",
   "license": "MIT",