🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Reconcile the package identity in the verification records.

These artifacts describe publishing the unscoped pharn package, while this PR targets scoped @pharn-dev/pharn. That mismatch can mislead release operators and invalidate the recorded tarball/package checks. Update the records to the scoped identity, or clearly mark them as superseded historical artifacts.

• .dev/features/canonical-npm-name/PLAN.md#L1-L5: replace the unscoped package objective or mark this plan superseded.
• .dev/features/canonical-npm-name/GRILL.md#L29-L34: update the tarball/package assertions to match the scoped package.
• .dev/features/canonical-npm-name/REVIEW.md#L1-L5: align the reviewed rename direction with the current package identity.
• .dev/features/npm-publish-metadata/SHIP.md#L21-L21: correct the nonsensical pharn→pharn metadata statement and record the actual rename.

[uncategorized] ~5-~5: The official name of this software platform is spelled with a capital “H”.
Context: ...+ docs/repo-surface (*.md, docs/**, .github/ISSUE_TEMPLATE/**) — **no src/ code-...

(GITHUB)

• .dev/features/canonical-npm-name/PLAN.md#L1-L5 (this comment)
• .dev/features/canonical-npm-name/GRILL.md#L29-L34
• .dev/features/canonical-npm-name/REVIEW.md#L1-L5
• .dev/features/npm-publish-metadata/SHIP.md#L21-L21

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/canonical-npm-name/PLAN.md around lines 1 - 5, Reconcile the
verification records with the current scoped package identity: in
.dev/features/canonical-npm-name/PLAN.md lines 1-5, replace the unscoped pharn
objective or mark the plan superseded; in
.dev/features/canonical-npm-name/GRILL.md lines 29-34, update tarball and
package assertions to `@pharn-dev/pharn`; in
.dev/features/canonical-npm-name/REVIEW.md lines 1-5, align the reviewed rename
direction with the scoped identity; and in
.dev/features/npm-publish-metadata/SHIP.md line 21, replace the pharn→pharn
statement with the actual `@pharn-dev/pharn` rename.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Correct the package identity in this ship record.

This record says the package is changing from @pharn-dev/pharn to unscoped pharn, and advises deprecating the scoped package. The PR objective is the opposite: pharn-cli → @pharn-dev/pharn, with the installed binary remaining pharn. Update this artifact to describe the scoped publish, or remove it if it is stale historical output; otherwise the active ship record can mislead release and deprecation steps.

Also applies to: 45-47

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/canonical-npm-name/SHIP.md around lines 3 - 4, Correct the
ship record’s package identity and release direction: update the increment
description to rename `pharn-cli` to `@pharn-dev/pharn` while preserving the
installed `pharn` binary, and remove the unscoped-package/deprecation guidance.
If this is stale historical output rather than an active record, remove the
artifact instead.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Do not leave the ship verification verdict as FAIL.

The ship helper computes a green floor only when verify.verdict === "PASS". With validate: 1, this artifact blocks shipping despite describing the failure as pre-existing. Either make validate pass by excluding the generated test-*/ fixtures, or update the ship policy and report contract to explicitly accept pre-existing failures.

Based on the supplied .dev/floor/check-ship.mjs contract, floorGreen requires a PASS verification verdict. Based on learnings, all CI gates must pass.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/canonical-npm-name/verify-report.json around lines 8 - 12,
Update the verification artifact and its underlying validation flow so the
validate gate passes rather than leaving verdict as FAIL; exclude generated
test-*/ fixtures from validation as appropriate. Ensure the resulting
verify.verdict is PASS and failing_gates is empty, preserving the
.dev/floor/check-ship.mjs contract and requiring all CI gates to pass.

Source: Learnings

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Use the scoped npm package name from the PR contract.

The objective requires @pharn-dev/pharn; this plan still describes the package as unscoped pharn and implies npx pharn@latest. Keep the executable name pharn, but use the scoped package name in metadata and install instructions.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/npm-publish-metadata/PLAN.md around lines 10 - 13, The plan
should use the scoped npm package name `@pharn-dev/pharn` throughout package
metadata and installation instructions, while retaining pharn as the
executable/bin name. Update the package.json, README.md, CHANGELOG.md, and
CLAUDE.md entries to replace unscoped package references and change the npx
command to target `@pharn-dev/pharn`.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Align repository metadata claims with the actual package configuration.

The plan and grill record pharn-dev/pharn as the exact repository URL, but the supplied package.json evidence still points to pharn-dev/pharn-cli. This must be either an intentional metadata migration or an inaccurate verification record.

• .dev/features/npm-publish-metadata/PLAN.md#L24-L27: update the concrete metadata claim or change package.json consistently.
• .dev/features/npm-publish-metadata/GRILL.md#L51-L51: remove the “EXACT” assertion until it matches the actual package metadata.

• .dev/features/npm-publish-metadata/PLAN.md#L24-L27 (this comment)
• .dev/features/npm-publish-metadata/GRILL.md#L51-L51

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/npm-publish-metadata/PLAN.md around lines 24 - 27, Align the
repository metadata claim with the actual package configuration: in
.dev/features/npm-publish-metadata/PLAN.md lines 24-27, either update the
documented repository URL to pharn-dev/pharn-cli or change package.json
consistently to pharn-dev/pharn; in .dev/features/npm-publish-metadata/GRILL.md
line 51, remove the “EXACT” assertion unless the package metadata is updated to
match.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== workflow files =="
git ls-files .github/workflows || true

echo
echo "== publish workflow =="
if [ -f .github/workflows/publish.yml ]; then
  cat -n .github/workflows/publish.yml
fi

echo
echo "== zizmor references / secrets usage in publish workflow =="
rg -n "npm_cache|cache|NPM_TOKEN|npm publish|setup-node|permissions|contents|contents:|github-token|id-token|GITHUB_TOKEN|zizmor" .github/workflows/publish.yml || true

echo
echo "== all github token / npm cache references in workflows =="
rg -n "github-token:|GITHUB_TOKEN|NPM_TOKEN|npm_cache|actions/cache|setup-node|permissions:" .github/workflows || true

Repository: pharn-dev/pharn-cli

Length of output: 3071

🌐 Web query:

zizmor npm cache poisoning setup-node cache npm publish NPM_TOKEN

💡 Result:

The connection between zizmor, npm, and cache poisoning arises primarily from the default behavior of actions/setup-node (v5 and later), which automatically caches package manager dependencies [1][2][3]. If a repository's cache is poisoned by a low-privileged workflow—such as one triggered by an untrusted event—this poisoned cache can be consumed by a high-privileged release workflow, potentially leading to the injection of malicious code into a published npm package [4][3][5]. Zizmor, a static analysis tool for GitHub Actions, includes a cache-poisoning audit specifically designed to detect this risk [1][6][7]. Key security considerations and mitigations include: 1. Disable Automatic Caching in Sensitive Workflows: For workflows with elevated privileges (such as those performing npm publishing), it is strongly recommended to explicitly disable automatic npm caching by setting package-manager-cache: false in your actions/setup-node step [4][2][8][3]. 2. Use Trusted Publishing: Avoid manual npm tokens (NPM_TOKEN) in CI/CD secrets whenever possible [9][10]. Instead, use npm's Trusted Publishing mechanism, which allows GitHub Actions to securely authenticate with npm via short-lived, OIDC-based identity tokens [9][5]. Zizmor can detect and flag workflows that still rely on manual tokens despite having the necessary permissions for trusted publishing [9]. 3. GitHub Actions Cache Security: GitHub has implemented improvements to mitigate cache-based privilege escalation, including issuing read-only cache tokens for untrusted triggers on the default branch [11]. However, this does not eliminate the need for proper configuration in your own workflows [3]. 4. Zizmor Usage: Zizmor automatically scans for these patterns [7][12]. If you encounter a false positive or have unique requirements, you can review its audit rules [13] and documentation [14]. Zizmor also tracks various npm publishing patterns to ensure they align with security best practices [9][10]. For further guidance, consult the official documentation for actions/setup-node regarding cache poisoning mitigation [8] and the zizmor documentation for audit specifics [14][13].

Citations:

• 1: [BUG]: cache-poisoning rule doesn't support breaking change of actions/setup-node v5 zizmorcore/zizmor#1152
• 2: docs: Update caching recommendations to mitigate cache poisoning risks actions/setup-node#1567
• 3: npm/documentation@cad232f
• 4: ci: disable setup-node caching in JS release workflow grafana/augurs#517
• 5: https://github.com/lullu57/gh-actions-demo-cache-poisoning
• 6: [BUG]: cache-poisoning rule doesn't support breaking change of actions/setup-node v6 zizmorcore/zizmor#1485
• 7: https://zizmor.sh/
• 8: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md
• 9: feat: add npm trusted publishing detection zizmorcore/zizmor#1161
• 10: Feature: more publishing patterns for JS zizmorcore/zizmor#1493
• 11: https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/
• 12: https://github.com/zizmorcore/zizmor
• 13: https://docs.zizmor.sh/audits/
• 14: https://docs.zizmor.sh/

Remove npm caching from the privileged publish job.

actions/setup-node caches dependencies automatically with cache: npm, and this job also runs with ids: write for provenance while publishing authenticated with NPM_TOKEN. Keep caching only in non-publishing CI jobs; disable it here with package-manager-cache: false.

[error] 21-21: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): this step

(cache-poisoning)

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/publish.yml around lines 21 - 24, Update the
actions/setup-node configuration in the privileged publish job to disable
automatic package-manager caching by setting package-manager-cache to false, and
remove the cache: npm setting. Leave dependency caching enabled only in the
non-publishing CI jobs.

Source: Linters/SAST tools

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Fix the duplicate bin names.

The release note currently says the release exposes both pharn and pharn bins. Restore the historical name or state that only the pharn binary is exposed.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@CHANGELOG.md` around lines 96 - 97, Update the initial release note to remove
the duplicate bin names, restoring the historical second binary name or clearly
stating that only the pharn binary is exposed.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Align the security boundary with the current installation layout.

Both documents understate the write surface by treating .claude/ as the destination for installed methodology. The current flow also writes capabilities and fixed product surfaces outside .claude/; the threat model and security policy should name or clearly abstract all of those paths.

• SECURITY.md#L3-L9: describe writes to .claude/, the mirrored capability layout, root product surfaces, and pharn.config.json.
• THREAT-MODEL.md#L18-L22: expand Surface A beyond .claude/ so the residual analysis covers every installed location.

[style] ~7-~7: Consider an alternative for the overused word “exactly”.
Context: ...metry. Its security-relevant surface is exactly the two things that cross a trust bound...

(EXACTLY_PRECISELY)

• SECURITY.md#L3-L9 (this comment)
• THREAT-MODEL.md#L18-L22

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@SECURITY.md` around lines 3 - 9, The security documentation understates the
installation write surface. In SECURITY.md, update the description to cover
.claude/, the mirrored capability layout, root product surfaces, and
pharn.config.json; in THREAT-MODEL.md, expand Surface A beyond .claude/ to
include every installed location. Preserve the existing remote-input and
safe-write security model while ensuring both documents describe the current
layout consistently.