feat: implement issue #870 — [#850] standards-deploy driver deploys BROKEN dev-lead pins (@dev-lead/v14-* has no tag — uses release major, not channel major)

[don-petry]

User description

Closes #870

Implemented by dev-lead agent. Please review.

---

CodeAnt-AI Description

Use channel tags for workflow pinning and block broken refs

What Changed

• Workflow stubs now pin to the channel tag that matches the repo tier, instead of using the reusable’s release version.
• If a computed pin does not exist on the source repo, the deploy now stops instead of opening a PR with a broken reference.
• Test coverage was updated to reflect channel-based behavior, including the dev-lead case where release version v14 must still pin to the valid v1 channel tag.

Impact

✅ Fewer broken workflow pins
✅ No PRs with non-resolving reusable refs
✅ Correct pins for release/version mismatches

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

Summary by CodeRabbit

• Bug Fixes

  • Ring-managed workflow pins now use the correct channel major rather than unrelated release versions.
  • Deployments now verify that computed workflow references exist before creating a pull request, preventing unresolved pins.

• Tests

  • Added regression coverage for channel-major pinning, missing tag references, tier mismatches, and compliant workflow stubs.
  • Updated deployment scenarios to reflect channel-based version tags.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	c9daeb2	Jul 22, 2026 · 06:37	06:39

_{Updated in place by CodeAnt AI · last 5 reviews}

[coderabbitai]

Warning

Review limit reached

@don-petry, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 26 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: c1afa230-188a-4148-a506-e54ed27235d0

📥 Commits

Reviewing files that changed from the base of the PR and between c9daeb2 and a8ced63.

📒 Files selected for processing (4)

• scripts/deploy-standard-workflows.sh
• scripts/lib/ring-pins.sh
• test/scripts/deploy-standard-workflows/emit-vform.bats
• test/scripts/lib/ring-pins.bats

📝 Walkthrough

Walkthrough

Ring-managed workflow deployment now derives pins from channel-major tags rather than release majors, verifies computed tags exist, and skips unresolved refs. Tests update mocked GitHub responses and cover channel-major selection, compliance, re-pinning, and missing-tag handling.

Changes

Channel-major pinning

Layer / File(s)	Summary
Channel-major helper functions scripts/lib/ring-pins.sh, test/scripts/lib/ring-pins.bats	Adds channel-major extraction, host tag lookup, tag existence checks, and corresponding tests.
Deployment channel pin integration scripts/deploy-standard-workflows.sh	Uses channel majors for compliance and emitted refs, and skips deployment when the computed tag does not exist.
Deployment behavior regression coverage test/scripts/deploy-standard-workflows/*.bats	Updates stubs to channel-tag refs and covers channel-major pinning, compliance states, exemptions, and unresolved refs.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• petry-projects/.github#691: Updates ring-managed reusable workflow coverage used by this pinning logic.
• petry-projects/.github#699: Modifies the same ring pinning and deployment functions.

Suggested labels: needs-human-review

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is specific and directly describes the channel-major pinning fix for broken dev-lead refs.
Linked Issues check	✅ Passed	The PR updates the driver to use existing channel majors, validates tag existence, and adds regression coverage for the broken refs.
Out of Scope Changes check	✅ Passed	All listed changes are tightly related to the channel-major pinning fix and its supporting tests.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev-lead/issue-870-20260722-0612

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[don-petry]

Note

@don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically.
Next attempt after: 2026-07-22T07:08:07Z

[qodo-code-review]

PR Summary by Qodo

Fix standards-deploy pinning to use channel major, not release major

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Fixes #870: the standards-deploy driver pinned stubs using the RELEASE major (e.g. dev-lead's
 v14.0.0) instead of the CHANNEL major (v1-), producing tags that never resolve.
• Adds ring_highest_channel_major, ring_host_current_channel_major, and ring_tag_exists in
 ring-pins.sh to derive the caller-contract major from existing channel tags and verify a computed
 ref actually resolves.
• Updates deploy-standard-workflows.sh to use the channel-major helpers for drift detection and
 emitted refs, and adds an assert-exists guard that refuses to deploy a non-resolving pin.
• Extensive bats test updates/additions covering the channel-vs-release major distinction and the
 new tag-existence guard, including the exact dev-lead/bmad-bgreat-suite regression scenario.

Diagram

graph TD
  A["deploy-standard-workflows.sh"] --> B["emit_ref_for()"]
  A --> C["is_already_compliant()"]
  B --> D["ring_host_current_channel_major()"]
  C --> D
  D --> E["ring_highest_channel_major()"]
  D --> F[("GitHub tags API")]
  A --> G["ring_tag_exists()"] --> F
  G --> H{"Ref resolves?"}
  H -->|No| I["Refuse deploy - err"]
  H -->|Yes| J["Open sync PR"]

Loading

High-Level Assessment

The fix correctly distinguishes the caller-contract channel major from the internal release major and adds a defensive existence check before pinning — this is the right minimal fix given the existing ring-pins abstraction; no meaningfully different architecture was warranted for this bug fix.

Files changed (6) +265 / -50

Bug fix (2) +75 / -9

ring-pins.shAdd channel-major derivation and tag-existence helpers +48/-0

Add channel-major derivation and tag-existence helpers

• Introduces ring_highest_channel_major (parses <M>-<tier> channel tokens, ignoring release semver), ring_host_current_channel_major (gh-backed wrapper reading matching-refs), and ring_tag_exists (validates a ref resolves on the host before it is pinned).

scripts/lib/ring-pins.sh

deploy-standard-workflows.shSwitch drift/emit logic to channel major and add assert-exists guard +27/-9

Switch drift/emit logic to channel major and add assert-exists guard

• is_already_compliant and emit_ref_for now call ring_host_current_channel_major instead of ring_host_current_major so stubs are pinned/checked against the resolving channel tag. deploy_repo now validates the computed ref exists via ring_tag_exists before opening a PR, refusing non-resolving pins.

scripts/deploy-standard-workflows.sh

Tests (4) +190 / -41

ring-pins.batsAdd unit tests for channel-major and tag-existence helpers +75/-0

Add unit tests for channel-major and tag-existence helpers

• New tests cover ring_highest_channel_major (correctly ignoring release semver), ring_host_current_channel_major against a fake gh, and ring_tag_exists true/false behavior, including the dev-lead v14-release-vs-v1-channel regression case.

test/scripts/lib/ring-pins.bats

emit-vform.batsRework emit-vform tests around channel tags and add #870 regression tests +79/-22

Rework emit-vform tests around channel tags and add #870 regression tests

• Replaces GH_RELEASE_REFS fixtures with GH_MATCHING_REFS/channel_refs helper reflecting channel tags, adds GH_EXISTING_TAGS support for the new tag-existence probe, and adds dedicated #870 tests for the dev-lead channel-major pin and the assert-exists refusal.

test/scripts/deploy-standard-workflows/emit-vform.bats

feature-ideation-seed-repin.batsUpdate feature-ideation tests to use channel tag fixtures +22/-9

Update feature-ideation tests to use channel tag fixtures

• Renames the fake-gh fixture from release refs to full channel-tag sets across all feature-ideation and pr-auto-review test cases so major derivation matches the new channel-based logic.

test/scripts/deploy-standard-workflows/feature-ideation-seed-repin.bats

pr-auto-review-skip-override.batsUpdate pr-auto-review skip-override tests to channel tag fixtures +14/-10

Update pr-auto-review skip-override tests to channel tag fixtures

• Replaces release-tag environment fixtures with channel-tag fixtures and updated comments reflecting the channel-major terminology.

test/scripts/deploy-standard-workflows/pr-auto-review-skip-override.bats

[don-petry]

Dev-Lead — waiting on PR blockers (intent: review-changes)

PR: #871
No changes were committed, but the PR still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews). The retry cron will re-attempt automatically. Next attempt after: 2026-07-22T07:12:31Z

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 87 rules

1. Tag check conflates errors ✓ Resolved 🐞 Bug ☼ Reliability

Description

ring_tag_exists returns failure for any gh api error while suppressing all output, and deploy_repo
interprets that as “tag missing.” This can incorrectly refuse deployment and emit misleading
diagnostics during auth/rate-limit/network failures.

Code

scripts/lib/ring-pins.sh[R201-207]

+# ring_tag_exists <host-repo> <ref> -> 0 iff refs/tags/<ref> resolves on <host>.
+# The assert-exists guard: a computed channel ref is validated to exist before a
+# stub is pinned to it, so the deploy never opens a PR carrying a non-resolving
+# `@<base>/v<M>-<tier>` pin (#870). gh-backed. Requires GH_TOKEN.
+ring_tag_exists() {
+  gh api "repos/$1/git/ref/tags/$2" >/dev/null 2>&1
+}

Relevance

⭐⭐⭐ High

Team has accepted distinguishing gh API failures from real “missing” states (e.g., 404 vs
auth/rate-limit) in scripts (#808/#865).

PR-#808
PR-#865

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

ring_tag_exists() suppresses all output and returns only the gh api exit code; deploy_repo then
treats any non-zero as “does not resolve to a tag,” so API failures are indistinguishable from a
real missing tag.

scripts/lib/ring-pins.sh[201-207]
scripts/deploy-standard-workflows.sh[470-476]
PR-#865

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ring_tag_exists()` currently returns non-zero for *any* `gh api` failure and discards stderr/stdout. The caller then reports “does not resolve to a tag,” but that’s only correct for a 404; other failures should be treated as probe errors and surfaced distinctly (and likely fail the run).

### Issue Context
The deploy driver uses `ring_tag_exists()` in its assert-exists guard to prevent broken pins. Conflating operational failures with missing tags causes false refusals and misleading messages.

### Fix Focus Areas
- scripts/lib/ring-pins.sh[201-207]
- scripts/deploy-standard-workflows.sh[470-476]

### Suggested fix
- Implement a probe that captures stderr and distinguishes cases:
 - If stderr indicates HTTP 404 → treat as “missing tag” (return 1).
 - Otherwise → treat as “probe failed” (return 2 or non-zero with a distinct message).
- Update the deploy guard to:
 - emit a “probe failed” error for non-404 failures, and
 - fail the run (or at minimum mark the run failed) rather than silently continuing.
- Avoid `>/dev/null 2>&1` unless the caller already captured and logged diagnostics.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Channel-major lookup fails open ✓ Resolved 🐞 Bug ☼ Reliability

Description

ring_host_current_channel_major returns success with empty output when the matching-refs call fails,
so callers treat transient API failures as “no channel tags” and fall back to bare-tier pins. This
can suppress required v-form migration or produce incorrect pins during outages.

Code

scripts/lib/ring-pins.sh[R188-198]

+ring_host_current_channel_major() {
+  local host="$1" base="$2" refs
+  refs="$(gh api "repos/${host}/git/matching-refs/tags/${base}/v" \
+            --jq '.[]?.ref' 2>/dev/null \
+          | sed -n "s#^refs/tags/${base}/v##p")" || {
+    echo "Warning: failed to fetch matching refs for ${host}/${base}" >&2
+    return 0
+  }
+  # shellcheck disable=SC2086
+  ring_highest_channel_major $refs
+  return 0

Relevance

⭐⭐ Medium

Similar “gh api failure treated as empty” hardening was only partially accepted previously (#699);
no clear enforcement either way.

PR-#699

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The function’s failure branch explicitly returns 0 with no major, and deploy-standard-workflows
consumes that value to compute the pin; this makes an API failure indistinguishable from “no channel
tags exist.”

scripts/lib/ring-pins.sh[188-199]
scripts/deploy-standard-workflows.sh[372-380]
scripts/deploy-standard-workflows.sh[309-325]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ring_host_current_channel_major()` prints a warning and returns 0 with empty output when it cannot query tags. Call sites interpret empty output as a legitimate “no channel tags exist” state, which changes deploy behavior (bare-tier fallback) during transient GitHub/API failures.

### Issue Context
The deploy driver uses the channel-major to decide whether to enforce v-form pins. Treating probe failure as “no tags” is a fail-open behavior that can prevent migrations or cause incorrect repins.

### Fix Focus Areas
- scripts/lib/ring-pins.sh[188-199]
- scripts/deploy-standard-workflows.sh[372-380]
- scripts/deploy-standard-workflows.sh[309-325]

### Suggested fix
- Make `ring_host_current_channel_major` return non-zero on probe failure (and keep empty+0 strictly for the real “no matching tags” case).
- Update callers to handle this explicitly without tripping `set -e`, e.g.:
 - `if ! major="$(ring_host_current_channel_major ...)"; then err "probe failed"; return 1; fi`
- Decide policy: for deploy sweeps, prefer failing the run (or marking it failed) if channel-major cannot be determined, rather than silently falling back to bare-tier pins.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. deploy-standard-workflows.sh logs error, exits 0 ✓ Resolved 📘 Rule violation ≡ Correctness

Description

When ring_tag_exists/the new assert-exists guard fails in deploy_repo, the script logs an
ERROR but then continues and can ultimately exit with status 0, misleading callers/CI into
treating a refused/partial deploy as successful. The newly added test further reinforces this
success-on-error behavior by asserting status -eq 0 for the error path.

Code

scripts/deploy-standard-workflows.sh[R466-476]

+    # assert-exists (#870): never pin a stub to a channel ref that has no tag. A
+    # computed `v<M>-<tier>` (or bare tier) that does not resolve on the host would
+    # break the caller's workflow on the next run, so refuse it here rather than
+    # open a PR carrying a non-resolving pin.
+    if [[ -n "$emit" ]]; then
+      local emit_host
+      emit_host="$(reusable_host_of "$template")"
+      if ! ring_tag_exists "$emit_host" "$emit"; then
+        err "$repo/$workflow — computed channel ref @${emit} does not resolve to a tag on ${emit_host}; refusing to deploy a non-resolving pin"
+        continue
+      fi

Relevance

⭐⭐ Medium

Mixed history: team sometimes accepts fail-closed exits (#590/#624) but also rejects “exit non-zero
on skipped” (#757).

PR-#590
PR-#624
PR-#757

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2238078 requires that outward-facing success indicators not signal success when an
error was encountered, yet the new assert-exists branch emits an ERROR/logs via err when the
computed pin/tag doesn’t resolve and then continues without setting any failure status. Because
err() only writes to stderr and main() does not aggregate or check any accumulated error state,
the script’s process exit code remains successful even when deployments are refused, and the added
bats test explicitly expects a 0 exit status for that error scenario.

Rule 2238078: Do not report success when an error was encountered
scripts/deploy-standard-workflows.sh[465-477]
scripts/deploy-standard-workflows.sh[183-187]
test/scripts/deploy-standard-workflows/emit-vform.bats[214-226]
scripts/deploy-standard-workflows.sh[465-476]
scripts/deploy-standard-workflows.sh[531-560]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`scripts/deploy-standard-workflows.sh` can hit an error condition where a computed channel ref/pin tag does not resolve (via `ring_tag_exists` / the new `assert-exists` guard), log an `ERROR`, and still return exit code `0`. This both violates the requirement (PR Compliance ID 2238078) to not report success after errors and risks CI/automation treating refused or partial deployments as successful.

## Issue Context
The behavior is introduced/triggered by the new `assert-exists (#870)` guard inside `deploy_repo()`: it logs an error and `continue`s, but `err()` is non-fatal (stderr only) and `main()` does not track/aggregate failures, so the overall run can still exit successfully while leaving some workflows undeployed. The test suite currently asserts `status -eq 0` for this error path, reinforcing the success-on-error contract.

## Fix Focus Areas
- scripts/deploy-standard-workflows.sh[183-187]
- scripts/deploy-standard-workflows.sh[465-477]
- scripts/deploy-standard-workflows.sh[531-560]
- test/scripts/deploy-standard-workflows/emit-vform.bats[214-226]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[donpetry-bot]

CI checks on this PR are still running. Once they complete, re-mention @donpetry-bot to trigger a fresh review.

Posted by the donpetry-bot PR-review cascade.

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In `@scripts/deploy-standard-workflows.sh`:
- Around line 466-477: Update the channel-ref validation around ring_tag_exists
to cache each (emit_host, emit) lookup and reuse the cached result across
workflows and repositories. Ensure both computed and bare-tier refs use the
cache, while preserving the existing refusal and error behavior for missing
tags.

In `@scripts/lib/ring-pins.sh`:
- Around line 182-199: Extract the duplicated gh API and sed matching-refs
pipeline from ring_host_current_major and ring_host_current_channel_major into
one shared parameterized helper. Have each function reuse that helper and apply
its respective highest-major matcher, while preserving the existing warning,
empty-result, and return behavior.
- Around line 201-208: Update ring_tag_exists to distinguish a genuinely missing
tag from unexpected gh api failures: preserve the successful result for
resolving refs and the expected not-found result for absent tags, but emit a
Warning including the gh failure details for authentication, rate-limit,
network, or other API errors. Ensure deploy_repo can still skip absent tags
while outages and authorization failures are surfaced instead of being reported
as missing tags.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 79a81a30-18a0-4c7a-8b94-cdc559919220

📥 Commits

Reviewing files that changed from the base of the PR and between 590d191 and c9daeb2.

📒 Files selected for processing (6)

• scripts/deploy-standard-workflows.sh
• scripts/lib/ring-pins.sh
• test/scripts/deploy-standard-workflows/emit-vform.bats
• test/scripts/deploy-standard-workflows/feature-ideation-seed-repin.bats
• test/scripts/deploy-standard-workflows/pr-auto-review-skip-override.bats
• test/scripts/lib/ring-pins.bats

[don-petry]

Dev-Lead — fix-reviews (applied)

Changes committed and pushed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[don-petry]

Dev-Lead — review-changes (no-changes)

No changes were needed for this PR.

[donpetry-bot]

Automated review — APPROVED ✓

Risk: MEDIUM
Reviewed commit: a8ced63dc0cbb9014c3a4b68967d0d0c4c8dd835
Review mode: triage-approved (single reviewer)

Summary

Fixes #870: the standards-deploy driver now derives workflow-stub pins from the highest existing CHANNEL tag major (ring_host_current_channel_major) instead of the release major, so dev-lead (release v14, channel v1) pins the resolving @dev-lead/v1- rather than the tagless @dev-lead/v14-. Adds an assert-exists guard (ring_tag_exists) that refuses to open a PR carrying a non-resolving pin and propagates failures to a non-zero exit. Comprehensive bats regression coverage, including the exact live dev-lead/bmad scenario.

Linked issue analysis

Issue #870 requires: (1) driver emits @dev-lead/v1- matching an existing channel tag, never a tagless release-major channel — implemented via ring_highest_channel_major which only matches - tokens and ignores release semver; (2) emitted refs validated to exist before opening a PR — implemented via ring_tag_exists assert-exists guard in deploy_repo with _OVERALL_FAILED exit propagation. Both code-side acceptance criteria are substantively addressed with regression tests (v14 release + v1 channel → v1-ring1; missing tier tag → refused, non-zero exit). The remaining acceptance items (correcting bmad-bgreat-suite's live pin, re-sweeping the 5 closed repos) are operational follow-ups outside this PR's scope.

Findings

No blocking findings. Prior bot-review findings were all addressed at the head commit: exit-code now propagates via _OVERALL_FAILED (deploy exits 1 on refused pins); ring_tag_exists distinguishes 404 from auth/rate-limit/network errors and warns on the latter while conservatively refusing the pin; channel-major probe fails closed (returns 1) so an API outage cannot silently downgrade to bare-tier pins. All 6 review threads resolved; CodeRabbit's changes-requested review was superseded by an APPROVED review of the head SHA. The run_secret_scanning MCP tool was not available in this environment; gitleaks CI passed (no secrets in the diff — shell logic and test fixtures only).

CI status

All checks green at head SHA a8ced63: ShellCheck, Lint, Lint and bats (x3), CodeQL, Analyze (actions), SonarCloud (quality gate passed), Secret scan (gitleaks), Agent Security Scan, AgentShield, npm audit, CodeRabbit — all SUCCESS. Two CANCELLED dev-lead dispatch/ci-relay entries are superseded agent-dispatch runs (later runs of the same checks succeeded); ecosystem audits (pip/cargo/go/pnpm) skipped as not applicable.

---

Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.

[donpetry-bot]

Automated review — APPROVED ✓

Risk: MEDIUM
Reviewed commit: a8ced63dc0cbb9014c3a4b68967d0d0c4c8dd835
Review mode: triage-approved (single reviewer)

Summary

Fixes #870: the standards-deploy driver now derives workflow-stub pins from the highest existing CHANNEL tag major (e.g. dev-lead/v1-) instead of the release major (v14, which has no channel tag), and adds an assert-exists guard (ring_tag_exists) that refuses to open a PR carrying a non-resolving pin. Channel-major probe failures now fail closed (exit 1) instead of silently falling back to bare-tier pins. Comprehensive bats regression coverage including the exact dev-lead v14-release/v1-channel case.

Linked issue analysis

Issue #870 (broken @dev-lead/v14-* pins) is substantively addressed. Acceptance items 1 and 2 (channel-major derivation via new ring_highest_channel_major/ring_host_current_channel_major, and tag-existence validation before deploy) are implemented with regression tests: a dev-lead consumer with release v14 + channel v1 tags emits @dev-lead/v1-ring1, and a computed ref with no tag is refused with exit 1. Acceptance items 3 and 4 (correcting bmad-bgreat-suite's live pin, re-sweeping the 5 closed repos) are operational follow-ups outside this PR's code scope.

Findings

No blocking findings.

• Fail-closed semantics are correct: ring_host_current_channel_major returns 1 on gh probe error (vs. the legacy fail-open ring_host_current_major, retained for its existing callers), and deploy_repo aggregates failures into _OVERALL_FAILED → exit 1.
• ring_tag_exists distinguishes 404 from transient errors (warns on non-404) and caches per-process; a transient error is cached as failure for the run — acceptable fail-closed behavior, non-blocking.
• All 6 prior review threads (CodeAnt, CodeRabbit) are resolved; CodeRabbit's initial CHANGES_REQUESTED was dismissed after fixes and superseded by its APPROVED review. reviewDecision is APPROVED.
• Secret scan: run_secret_scanning MCP tool unavailable in this environment; gitleaks CI check passed, and the diff introduces no credentials, tokens, or auth changes.

CI status

All quality gates green on head commit: Lint, ShellCheck, bats, CodeQL (actions), SonarCloud quality gate, Secret scan (gitleaks), Agent Security Scan, agent-shield, npm audit. Ecosystem-inapplicable audits skipped (pip/cargo/govulncheck/pnpm). The lone CANCELLED dev-lead dispatch/ci-relay entries are superseded duplicates of the same checks that completed SUCCESS.

---

Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.