fix(release): restore a clean npm deployment path (#195)

The published v7.0.10 package is already on npm, but the GitHub npm
deployment stayed red because that release ran against a failing tag-era
commit. This patch advances the next publish target to 7.0.11, keeps the
README release notes in sync, and removes the duplicate tag-push trigger so
GitHub tracks one canonical release deployment instead of a paired
release-plus-tag run.

Constraint: v7.0.10 is already published on npm, so rerunning that release would collide
Rejected: rerun the existing v7.0.10 workflow | publish step would still target an already-taken version
Rejected: keep the tag-push trigger and accept duplicate deploy cards | leaves the npm environment noisy and misleading
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: keep the npm publish workflow on a single canonical trigger path unless a future release process explicitly needs tag-push publishes again
Tested: npm test; node --check bin/multiagent-safety.js; npm pack --dry-run --cache .npm-cache; openspec validate agent-codex-make-npm-deployment-green-2026-04-21-03-13 --type change --strict; openspec validate --specs
Not-tested: live GitHub release execution for v7.0.11 before merge

Co-authored-by: NagyVikt <nagy.viktordp@gmail.com>

Author: NagyVikt

.github/workflows/release.yml

@@ -2,9 +2,6 @@ name: Release to npm (provenance)
 
 on:
   workflow_dispatch:
-  push:
-    tags:
-      - 'v*'
   release:
     types: [published]
 

README.md

@@ -451,6 +451,11 @@ npm pack --dry-run
 <details>
 <summary><strong>v7.x</strong></summary>
 
+### v7.0.11
+- Fixed the npm release workflow trigger so publishes run from `release.published` or explicit manual dispatch, instead of double-firing on both the tag push and the release event.
+- This keeps the GitHub `npm` environment from collecting duplicate cancelled deploy cards for the same version and leaves one canonical release deployment to monitor.
+- Bumped `@imdeadpool/guardex` from `7.0.10` → `7.0.11` so the next release can publish cleanly after `7.0.10` was already taken on npm.
+
 ### v7.0.10
 - Primary user-facing long name is now **GitGuardex**. CLI/help presents `gitguardex` as the long-form command; `gx` stays the preferred short alias; `guardex` remains as legacy compatibility.
 - Installed Codex/Claude startup files now use `gitguardex` paths: `.codex/skills/gitguardex/SKILL.md` and `.claude/commands/gitguardex.md`.

openspec/changes/agent-codex-make-npm-deployment-green-2026-04-21-03-13/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-21

openspec/changes/agent-codex-make-npm-deployment-green-2026-04-21-03-13/notes.md

@@ -0,0 +1,5 @@
+# T1 Notes
+
+- Ship a clean follow-up release after `v7.0.10` failed its GitHub Actions release gate and left the npm deployment red.
+- Stop the duplicate tag-push publish path so the npm environment only reflects the real release run (or an explicit manual dispatch).
+- Bump the package metadata and README release notes together so the next publish can succeed without colliding with the already-published `7.0.10`.

openspec/changes/agent-codex-make-npm-deployment-green-2026-04-21-03-13/proposal.md

@@ -0,0 +1,15 @@
+## Why
+
+- The published `v7.0.10` release already exists on npm, but the GitHub `npm` deployment is still red because the release workflow ran from a failing tag-era commit.
+- The release workflow also double-triggers on both tag push and release publication, which leaves duplicate cancelled deployment cards in the `npm` environment even when the real release run is the one that matters.
+
+## What Changes
+
+- Bump the package metadata to `7.0.11` and add matching README release notes so the next publish targets a fresh npm version.
+- Limit the npm publish workflow to `release.published` and explicit manual dispatch so GitHub only records one canonical release deployment per version.
+- Add regression coverage that keeps the workflow on the single-release path.
+
+## Impact
+
+- Affects the package manifest, README release notes, release workflow trigger shape, and metadata regression tests.
+- Next step after merge is to publish a new GitHub release/tag so the corrected workflow produces the green npm deployment.

openspec/changes/agent-codex-make-npm-deployment-green-2026-04-21-03-13/specs/release-deployment/spec.md

@@ -0,0 +1,17 @@
+## ADDED Requirements
+
+### Requirement: canonical npm release trigger
+The release workflow SHALL publish npm releases from explicit release publication or manual dispatch only.
+
+#### Scenario: published release deployment
+- **WHEN** maintainers publish a GitHub release for a new package version
+- **THEN** the npm release workflow runs for that published release
+- **AND** the workflow does not also trigger a second publish job from the tag push for the same version.
+
+### Requirement: fresh publish target
+Each release-bound package version SHALL target an unpublished npm version and matching release notes.
+
+#### Scenario: next patch release after a failed deployment
+- **WHEN** the previous deployment is red but that version already exists on npm
+- **THEN** the package manifest advances to a new patch version
+- **AND** README release notes include a heading for that new version in the same change.

openspec/changes/agent-codex-make-npm-deployment-green-2026-04-21-03-13/tasks.md

@@ -0,0 +1,21 @@
+## 1. Specification
+
+- [x] 1.1 Finalize proposal scope and acceptance criteria for `agent-codex-make-npm-deployment-green-2026-04-21-03-13`.
+- [x] 1.2 Define normative requirements in `specs/release-deployment/spec.md`.
+
+## 2. Implementation
+
+- [x] 2.1 Implement scoped behavior changes.
+- [x] 2.2 Add/update focused regression coverage.
+
+## 3. Verification
+
+- [x] 3.1 Run targeted project verification commands.
+- [x] 3.2 Run `openspec validate agent-codex-make-npm-deployment-green-2026-04-21-03-13 --type change --strict`.
+- [x] 3.3 Run `openspec validate --specs`.
+
+## 4. Completion
+
+- [ ] 4.1 Finish the agent branch via PR merge + cleanup (`gx finish --via-pr --wait-for-merge --cleanup` or `bash scripts/agent-branch-finish.sh --branch <agent-branch> --base <base-branch> --via-pr --wait-for-merge --cleanup`).
+- [ ] 4.2 Record PR URL + final `MERGED` state in the completion handoff.
+- [ ] 4.3 Confirm sandbox cleanup (`git worktree list`, `git branch -a`) or capture a `BLOCKED:` handoff if merge/cleanup is pending.

package-lock.json

@@ -1,6 +1,6 @@
 {
   "name": "@imdeadpool/guardex",
-  "version": "7.0.10",
+  "version": "7.0.11",
   "description": "GitGuardex: hardened multi-agent git guardrails for parallel agent work.",
   "license": "MIT",
   "preferGlobal": true,

package.json

@@ -31,6 +31,14 @@ test('release workflow publishes with provenance in CI', () => {
   assert.match(workflow, /npm publish --provenance --access public/);
 });
 
+test('release workflow only publishes from published releases or manual dispatch', () => {
+  const workflowPath = path.join(repoRoot, '.github', 'workflows', 'release.yml');
+  const workflow = fs.readFileSync(workflowPath, 'utf8');
+  assert.match(workflow, /workflow_dispatch:/);
+  assert.match(workflow, /release:\s*\n\s*types:\s*\[published\]/);
+  assert.doesNotMatch(workflow, /\npush:\s*\n/);
+});
+
 test('README release notes include current package version', () => {
   const pkg = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
   const readme = fs.readFileSync(readmePath, 'utf8');