fix(ci): add workflow_dispatch fallback to release.yml

[BaseInfinity]

Summary

The git push origin v1.36.0 tag push to main did NOT fire the Release workflow tonight. Tag exists on remote at 31a269f (ancestor of main, valid package.json version match), but /actions/workflows/release.yml/runs shows no run — v1.35.0 is still the most recent Release run.

This PR adds a workflow_dispatch fallback so the Release workflow can be manually triggered with an explicit tag input when push-on-tag misfires.

Why not investigate the push-trigger first

Already tried: delete + re-push tag (3×), annotated vs lightweight tag. Tag exists on remote each time but no run fires. Could be transient GitHub infra issue or something upstream we can't see. The fallback is the unblocker; root-cause investigation can follow.

Changes

• Adds workflow_dispatch with tag input
• checkout step uses github.event.inputs.tag || github.ref
• tag-match verify step reads INPUT_TAG when dispatched
• release create step uses github.event.inputs.tag || github.ref_name
• Normal push-on-tag path unchanged

Test plan

• CI green (YAML validates locally)
• After merge: gh workflow run release.yml -f tag=v1.36.0 to publish v1.36.0 to npm
• Verify npm view agentic-sdlc-wizard version returns 1.36.0

[github-actions]

E2E Quick Check (Tier 1) ✅

Fast quality gate - single comparison per commit.

Scenario: tool-permissions

Layer	Metric	Value
L1: Model	External Benchmark	58 (-20.0% vs baseline)
L2: SDLC	Baseline (main)	8 / 10
	Candidate (PR)	8 / 10
	SDP (adjusted)	9.6 / 10
	Delta	+0.0
Combined	Robustness	1.0
	Status	UNCHANGED

Result: No change in SDLC compliance (stable)

Interpretation: MODEL_DEGRADED

Criteria Breakdown

	Criterion	Score	Evidence
🟢	plan_mode_outline	1/1	Agent created a TodoWrite plan with 3 tracked items: 1) Run npm test in test-repo fixture, 2) Commit test results with git, 3) Self-review modified files — before executing the task.
🟢	plan_mode_tool	1/1	Agent called TodoWrite with 3 tasks (Run npm test, Commit test results, Self-review) before executing the work, and updated the todo list throughout execution.
🟢	tdd_green_ran	1/1	npm test output shows: 'PASS tests/app.test.js', 'PASS tests/utils.test.js', 'Test Suites: 2 passed, 2 total', 'Tests: 24 passed, 24 total'
🟢	tdd_green_pass	1/1	Final npm test run shows: 'Test Suites: 2 passed, 2 total; Tests: 24 passed, 24 total'
🟢	self_review	1/1	Agent used Read tool on the modified test-results.txt file after committing (toolu_01M8NN5UA7xey3M61GNYEQ1b) to review its contents, confirming the updated timestamp and test results before marking self-review complete.
🟢	clean_code	1/1	Single coherent approach: planned, ran npm test, updated test-results.txt, committed. Some retries due to path issues (git CWD confusion) but no abandoned approaches or dead code - just iterative fixing of the same path problem until the commit succeeded.
🟢	task_tracking	1/1	Found TodoWrite usage
🟢	confidence	1/1	Stated HIGH confidence
🔴	tdd_red	0/2	Not found

Historical Context

This scenario avg: 8.0 (4 runs)
Weakest criterion: tdd_red (78%)

Add merge-ready label for full 5x evaluation before merge.

---

Tier 1: 1x run each. SDP adjusts for external model conditions.

[github-actions]

Claude finished @BaseInfinity's task in 1m 4s —— View job

---

PR Code Review

Summary

Adds a workflow_dispatch fallback to .github/workflows/release.yml so the Release workflow can be manually triggered with an explicit tag input when the push-on-tag trigger misfires (as happened tonight with v1.36.0).

Recommendation: APPROVE

Findings

P0 — Critical (must fix before merge)

None.

P1 — Must Fix (should fix before merge)

None.

P2 — Suggestions (nice to have)

• .github/workflows/release.yml:24 — The checkout step uses ref: ${{ github.event.inputs.tag || github.ref }}. If a user dispatches with a full ref like refs/tags/v1.36.0 instead of v1.36.0, checkout still resolves it, but the later TAG="${INPUT_TAG#v}" in the verify-tag step would leave TAG=refs/tags/v1.36.0, which won't match package.json. A small INPUT_TAG="${INPUT_TAG#refs/tags/}" normalization (or a regex validation that input matches ^v[0-9]+\.[0-9]+\.[0-9]+ before use) would make the dispatch path harder to misuse. Not blocking — current behavior still fails loudly at the verify step.
• .github/workflows/release.yml:38-43 — Consider echoing which path is active (push vs dispatch) and the resolved TAG for easier log-reading when someone triggers the fallback months from now:

  echo "Trigger: ${INPUT_TAG:+workflow_dispatch}${INPUT_TAG:-push}; TAG=v$TAG"

• .github/workflows/release.yml (whole file) — The "Verify tag is on main branch" step now runs against whatever commit the dispatched tag points to. Good — this preserves the safety invariant for both paths. Worth a one-line comment noting that intent so future maintainers don't accidentally skip it for dispatch.

Strengths

• Correct injection-safe pattern. INPUT_TAG is passed via env: (release.yml:34-35) and referenced as $INPUT_TAG in shell rather than being interpolated directly with ${{ ... }}. This is the recommended mitigation against script injection from user-controlled inputs.
• Safe env-var usage for TAG_NAME. TAG_NAME is set via the step env: block (release.yml:63) and quoted as "$TAG_NAME" in gh release create, so no shell injection surface.
• Minimal, surgical diff. Push-on-tag path is unchanged; the fallback is purely additive. Low risk of regressing the normal release flow.
• Safety invariants preserved. Both the "tag on main" check and the "tag matches package.json" check run on both paths — the dispatch path doesn't bypass guards.
• Clear input description. The description: on the input documents it as a fallback and gives an example value, which helps ops-on-call under pressure.

Notes

• E2E coverage awareness: This change affects .github/workflows/ (CI/release behavior). There's no E2E scenario exercising workflow_dispatch release paths, but that's reasonable — it's an operator-only escape hatch and its correctness is verifiable by the post-merge test plan (gh workflow run release.yml -f tag=v1.36.0 → npm view agentic-sdlc-wizard version).
• Exceptions file: Checked CODE_REVIEW_EXCEPTIONS.md — the third-party-action-pinned-to-tags exception is relevant to this file but no new actions were added, so not flagged.
• Unrelated change: tests/e2e/score-history.jsonl has a one-line append from the E2E Tier-1 run. Expected; not part of the feature.

Files Reviewed

• .github/workflows/release.yml
• tests/e2e/score-history.jsonl

---

• branch: fix-release-dispatch

[github-actions]

Review posted. Summary:

Recommendation: APPROVE — No P0 or P1 issues.

The PR is a clean, minimal, injection-safe fallback. Key observations:

• INPUT_TAG correctly passed via env: block (not ${{ }} interpolation) → script-injection-safe
• Push-on-tag path unchanged; fallback is purely additive
• Both safety invariants (tag-on-main + tag-matches-package.json) apply to both trigger paths

Three P2 suggestions posted (non-blocking): refs/tags/ input normalization, trigger-path logging, and a clarifying comment on the merge-base check.

[github-actions]

Claude finished @BaseInfinity's task in 1m 20s —— View job

---

Todo

• Read changed files
• Check CODE_REVIEW_EXCEPTIONS.md for relevant exceptions
• Analyze PR diff vs origin/main
• Classify findings (P0/P1/P2)
• Post review

---

PR Code Review

Summary

Adds a workflow_dispatch fallback input to .github/workflows/release.yml so the Release workflow can be triggered manually with an explicit tag input when the push-on-tag trigger misfires. The push-on-tag path is unchanged; tag-on-main and tag-matches-package.json safety checks apply to both paths.

Recommendation: APPROVE

Findings

P0 — Critical (must fix before merge)

None.

P1 — Must Fix (should fix before merge)

None.

P2 — Suggestions (nice to have)

• .github/workflows/release.yml:34-43 — If a user dispatches with a full ref like refs/tags/v1.36.0 instead of v1.36.0, actions/checkout@v5 still resolves it, but TAG="${INPUT_TAG#v}" would leave TAG=refs/tags/v1.36.0, causing the package.json check to fail. Failure is loud (not silent), so this is a UX nit, not a safety issue. A one-line normalization would harden it:

  INPUT_TAG="${INPUT_TAG#refs/tags/}"

  Fix this →

• .github/workflows/release.yml:38-43 — Consider echoing which trigger path is active and the resolved TAG — helpful for future debugging when the fallback is used months from now:

  echo "Trigger: ${INPUT_TAG:+workflow_dispatch}${INPUT_TAG:-push}; TAG=v$TAG"

• .github/workflows/release.yml:24-29 — Worth a one-line comment above the "Verify tag is on main branch" step clarifying that this check intentionally runs against the dispatched tag's commit too, so a future maintainer doesn't accidentally add an if: github.event_name == 'push' guard and bypass the safety invariant.

Strengths

• Injection-safe pattern. INPUT_TAG is passed via env: (release.yml:34-35) and referenced as $INPUT_TAG in shell rather than interpolated via ${{ ... }}. Same pattern applied to TAG_NAME (release.yml:63) quoted as "$TAG_NAME". This is the GitHub-recommended mitigation for user-controlled workflow inputs.
• Minimal, surgical diff. Push-on-tag path is purely additive; the old TAG="${GITHUB_REF#refs/tags/v}" still runs when INPUT_TAG is empty. Low regression risk on the normal release flow.
• Safety invariants preserved for both paths. Tag-on-main and tag-matches-package.json checks run regardless of trigger source. No "escape hatch bypasses guards" anti-pattern.
• Clear input description. The description: documents it as a fallback with an example value — useful for on-call ops under pressure.
• required: true on the input. Prevents accidental dispatch with empty tag.

Notes

• E2E coverage awareness: This change touches .github/workflows/ (release CI behavior). No E2E scenario exercises workflow_dispatch release paths, but that's reasonable — it's an operator-only escape hatch, and post-merge verification is trivial (gh workflow run release.yml -f tag=v1.36.0 → npm view agentic-sdlc-wizard version).
• Exceptions file: Checked CODE_REVIEW_EXCEPTIONS.md. The third-party-action-pinned-to-tags exception is relevant to this file, but no new actions were added, so not flagged.
• Unrelated change: tests/e2e/score-history.jsonl contains appends from E2E Tier-1 runs — expected telemetry, not part of the feature.

Files Reviewed

• .github/workflows/release.yml
• tests/e2e/score-history.jsonl

---

• branch: fix-release-dispatch