⚠️ Potential issue | 🟠 Major

cancel-in-progress: true on a release workflow can leave partial state.

This workflow pushes a git tag, creates a GitHub Release, and then publishes npmx-connector to npm in a downstream job. If a second push to release arrives mid-run (or this run is otherwise superseded), GitHub will SIGTERM the in-flight job and you can end up in inconsistent states such as:

• tag pushed but the GitHub Release never created (the 📝 Generate release notes / 🚀 Create GitHub Release steps get killed), or
• tag + Release exist but publish-connector is canceled before npm publish --provenance completes — leaving git/GitHub claiming a version that does not exist on the registry.

Releases on push to release are infrequent, so the throughput win from cancellation is negligible while the corruption risk is real. Recommend disabling cancellation on this workflow specifically.

 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
+  # Releases push tags, create GitHub releases, and publish to npm in sequence.
+  # Cancelling mid-run could leave a tag without a release, or a release without a published package.
+  cancel-in-progress: false

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release-tag.yml around lines 8 - 11, The concurrency block
currently sets "cancel-in-progress: true", which can leave release workflow
state inconsistent; change the concurrency configuration (the concurrency/group
and cancel-in-progress settings) so that cancel-in-progress is disabled for this
release workflow — e.g., remove or set "cancel-in-progress: false" in the
concurrency block that contains group: ${{ github.workflow }}-${{ github.ref }}
so in-flight release runs are allowed to finish instead of being terminated.

⚠️ Potential issue | 🟠 Major

🌐 Web query:

What version comment formats are accepted by zizmor's ref-version-mismatch audit? Does it accept "# tag=v1.2.3" or comments containing a "+" build metadata segment?

💡 Result:

Accepted version comment formats for zizmor’s ref-version-mismatch audit are determined by regexes that look for a version-like token inside a comment. 1) “# tag=v1.2.3” Yes, it accepts this format (and similar non-whitespace tags): it matches comments of the form # tag= where is captured as any non-whitespace sequence. So “# tag=v1.2.3” is accepted. 2) Comments containing a “+” build metadata segment (example: “v1.2.3+build.1”) No—based on the regexes’ allowed character sets for the version token, a “+” will not be captured/recognized as part of the version. Why: the audit’s “tag=” pattern captures any non-whitespace token, but the other supported “shorthand” patterns for version comments (e.g., “# v1.2.3-rc.1” and “# version: 2.8.0”) only allow prerelease parts made of [\w.-]+ and an optional hyphen prerelease, i.e. they do not include “+” in the allowed characters. In particular, “# v<digits...>(-[\w.-]+)?” does not permit “+” in the captured version. Practical guidance: if you want ref-version-mismatch to reliably recognize the version tag, stick to the supported forms like “# tag=vX.Y.Z” or “# vX.Y.Z-rc.1” / “# version: X.Y.Z” style, and avoid SemVer build metadata suffixes using “+”.

Citations:

• 1: https://github.com/woodruffw/zizmor/blob/main/crates/zizmor/src/audit/ref_version_mismatch.rs

Remove the + build metadata from the version comment to ensure zizmor's ref-version-mismatch audit properly recognises the version.

The +zephyr.6 suffix is not supported. The audit's version patterns only allow characters matching [\w.-] (word characters, dots, and hyphens), so the + will cause version matching to fail. Use # tag=v1.1.1 or # v1.1.1-zephyr.6 instead.

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/welcome-open.yml at line 22, The workflow comment on the
uses line referencing zephyrproject-rtos/action-first-interaction contains
unsupported build metadata "+zephyr.6"; update the comment after the action (the
tag comment on the line containing "uses:
zephyrproject-rtos/action-first-interaction@58853996b1ac504b8e0f6964301f369d2bb22e5c")
to remove the '+'—for example change "# tag=v1.1.1+zephyr.6" to "# tag=v1.1.1"
or to a dash-separated form like "# v1.1.1-zephyr.6" so the ref-version-mismatch
audit will match.

⚠️ Potential issue | 🟡 Minor

Concurrency fallback uses github.sha, which makes cancel-in-progress a no-op on push/merge_group.

For pull_request events, github.event.number resolves to the PR number, so this works as intended. However, for push and merge_group events github.event.number is undefined and the fallback github.sha is unique per commit, so each run lands in its own concurrency group and nothing is ever cancelled. The standard pattern (and what the PR description documents) is github.event.number || github.ref, which lets newer commits on the same ref cancel in-flight runs.

 concurrency:
-  group: ${{ github.workflow }}-${{ github.event.number || github.sha }}
+  group: ${{ github.workflow }}-${{ github.event.number || github.ref }}
   cancel-in-progress: true

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/zizmor.yml around lines 15 - 17, The concurrency group
fallback uses github.sha which is unique per commit and prevents
cancel-in-progress from working on push/merge_group; update the concurrency
block to use github.event.number || github.ref instead of github.event.number ||
github.sha so runs on the same ref share a group and newer runs cancel older
ones (look for the concurrency: group setting in the workflow YAML).

⚠️ Potential issue | 🟡 Minor

Missing Table of Contents entry for the new section.

The new "GitHub Actions security analysis" subsection has been added under "Development workflow" but is not listed in the TOC at lines 32–37. For consistency with the surrounding subsections (Available commands, Clearing caches…, Project structure, etc.), please add an entry.

 - [Development workflow](`#development-workflow`)
   - [Available commands](`#available-commands`)
+  - [GitHub Actions security analysis](`#github-actions-security-analysis`)
   - [Clearing caches during development](`#clearing-caches-during-development`)
   - [Project structure](`#project-structure`)
   - [Local connector CLI](`#local-connector-cli`)
   - [Mock connector (for local development)](`#mock-connector-for-local-development`)

Verify each finding against the current code and only fix it if needed.

In `@CONTRIBUTING.md` around lines 137 - 157, Add a Table of Contents entry for
the new subsection titled "GitHub Actions security analysis" so the TOC under
"Development workflow" includes this item; update the TOC block (the list around
the existing "Available commands", "Clearing caches…", "Project structure"
entries) to include a matching bullet/link for "GitHub Actions security
analysis" (use the same anchor style/format as other TOC items) so the new
subsection appears in the document navigation.