CLI Standardization

[fqjony]

No description provided.

To fix the problem, explicitly set permissions in this workflow, so the GITHUB_TOKEN used by the release job (and any called workflows) is constrained to the least privileges needed. Since this workflow’s job only delegates to npm-release-ops.yml and uses an npm token secret for publishing, a conservative default is to set contents: read at the workflow level. If the called workflow requires additional scopes (for example, to create releases or tags), those should be added there, but with only the snippet given we should not assume extra requirements.

The single best change, without altering existing functionality, is to add a root-level permissions block (aligned with on: and jobs:) specifying contents: read. This establishes a minimal default for all jobs in this workflow, including release, while still allowing the called workflow to further reduce permissions if it wants. We do not change any other lines or behavior.

Concretely, in .github/workflows/_release-cli.yml, after the on: block and before jobs:, insert:

permissions:
  contents: read

No additional methods, imports, or definitions are required since this is purely a YAML configuration change for GitHub Actions.

To fix the problem, add an explicit permissions block at the top level of the workflow so that all jobs without their own permissions (here: config and test) run with least-privilege GITHUB_TOKEN access. The release job already has its own permissions block, which will override the top-level one, so we leave it unchanged.

The best minimal, non‑functional change is:

• Add permissions: contents: read near the top of .github/workflows/npm-release-ops.yml, alongside name and on.
• This will ensure that config and test can still check out code (checkout requires contents: read) but won’t have unnecessary write permissions.
• No imports, additional methods, or other file changes are required.

Concretely, insert:

permissions:
  contents: read

after the name: NPM Release line (or anywhere at the root level before jobs:).

In general, the fix is to explicitly declare permissions for the workflow or for each job, granting only what is required. Here, the release job already has a tailored permissions block (contents: write, id-token: write). The config and test jobs only read repository contents and use secrets; they do not push changes or modify GitHub resources. So we should add a restrictive permissions block to those jobs (or at the workflow root) that limits GITHUB_TOKEN to read-only. To avoid altering existing behavior for the release job, we will set permissions: contents: read at the workflow root, so it applies to all jobs by default, while the existing release job permissions block will override this as needed.

Concretely, in .github/workflows/npm-release-ops.yml, insert a top-level permissions: block right after the name: NPM Release line. This block will specify contents: read, which is the minimal permission required for actions/checkout and reading the repository during config and test. We do not need to modify the release job’s permissions because job-level permissions override the workflow-level defaults. No additional imports or external libraries are needed since this is a YAML configuration change only.