Skip to content

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

Closed
#871
Closed
[#850] standards-deploy driver deploys BROKEN dev-lead pins (@dev-lead/v14-* has no tag — uses release major, not channel major)#870
#871
Labels
dev-leadFor dev-lead agent pickup

Description

@don-petry
don-petry
opened on Jul 22, 2026

Regression surfaced during #857 convergence — the standards-deploy driver deploys BROKEN dev-lead pins.

Symptom

The driver (scripts/deploy-standard-workflows.sh + scripts/lib/ring-pins.sh emit_vform) re-pins each consumer's dev-lead.yml stub to @dev-lead/v14-<tier> (e.g. dev-lead/v14-ring1, dev-lead/v14-stable). That channel tag does not exist — dev-lead's only v-form channel tags in .github-private are dev-lead/v1-{stable,next,ring0,ring1}. A uses: …@dev-lead/v14-ring1 ref fails to resolve, breaking the caller's dev-lead workflow.

Root cause

emit_vform derives the major from dev-lead's latest release tag (dev-lead/v14.0.0) instead of the highest existing channel major. But the channel major is the reusable's caller-contract version (intentionally v1 — a stable API), distinct from the internal release version (v14). The moving dev-lead/v1-stable tag already points at the v14.0.0 commit; that is the correct model. #860's template correctly pins dev-lead/v1-stable; the driver overrides it with a computed v14 and even leaves the stub comment saying v1-stable (comment/ref drift — caught by qodo).

Impact (2026-07-22)

  • bmad-bgreat-suite#409 MERGED → bmad's dev-lead.yml now pins the broken @dev-lead/v14-ring1 (regressed from a working bare dev-lead/stable). Live broken — needs correction to dev-lead/v1-ring1.
  • 5 in-flight convergence PRs (broodly#438, markets#365, TalkTerm#400, google-app-scripts#476, broodminder-export#64) were closed before merge to prevent spreading the broken pin.
  • Only dev-lead is affected — every other agent's channel-major == release-major (v1 or v2), so their pins are correct.

Fix

emit_vform (and the audit's expected-pin computation) must pin the highest major for which a <agent>/v<M>-<tier> CHANNEL tag actually exists (equivalently, match the template's literal channel major) — NOT the latest release major. Add a regression test: an agent whose release major (v14) exceeds its highest channel major (v1) must emit v1-<tier>, and the emitted ref must correspond to an existing tag (assert-exists).

Acceptance

  • Driver emits @dev-lead/v1-<tier> for dev-lead consumers (matching the existing channel tag), never a release-major channel that has no tag.
  • Emitted channel ref is validated to exist as a tag before opening the PR (no non-resolving pins).
  • bmad-bgreat-suite's dev-lead.yml corrected to dev-lead/v1-ring1.
  • Re-sweep re-opens the 5 closed repos with correct pins; audit shows 0 wrong-channel-pin findings.

Refs: Epic #850, #857 (convergence), #861 (deploy v-form logic), #860 (template pins), #657 (channel model).

Activity

  1. don-petry
    added
    dev-leadFor dev-lead agent pickup
    on Jul 22, 2026

  2. don-petry commented on Jul 22, 2026

    @don-petry
    don-petry
    on Jul 22, 2026
    ContributorAuthor

    Dev-Lead Implementation Plan

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

    Scope

    Make the deploy driver derive the channel major from the highest existing <agent>/v<M>-<tier> CHANNEL tag (dev-lead → v1) instead of the latest release semver tag (dev-lead → v14), and validate the emitted channel ref actually resolves to a tag before opening a PR.

    Root cause

    emit_ref_for / is_already_compliant call ring_host_current_major, which parses the reusable's release tags (dev-lead/v14.0.0) and returns 14. dev-lead's caller-contract channel tags are dev-lead/v1-<tier>, so the driver pins the non-resolving @dev-lead/v14-<tier>. Every other agent has channel-major == release-major, so only dev-lead is affected.

    Implementation Checklist

    • scripts/lib/ring-pins.sh: add ring_highest_channel_major (pure — highest M among v<M>-<tier> channel tokens, ignores release semver), ring_host_current_channel_major <host> <base> (gh-backed, from channel tags), and ring_tag_exists <host> <ref> (assert a ref resolves).
    • scripts/deploy-standard-workflows.sh: emit_ref_for and is_already_compliant use ring_host_current_channel_major instead of ring_host_current_major.
    • scripts/deploy-standard-workflows.sh: deploy_repo validates the computed emit ref exists (ring_tag_exists) before adding it to the PR — refuse a non-resolving pin.

    Tests to Write

    Test Command

    ./node_modules/.bin/bats test/scripts/deploy-standard-workflows/emit-vform.bats test/scripts/lib/ring-pins.bats (full suite before finishing)

  3. don-petry commented on Jul 22, 2026

    @don-petry
    don-petry
    on Jul 22, 2026
    ContributorAuthor

    ✅ Issue #870 — implemented (dev-lead agent)

    Root-caused and fixed the release-vs-channel major mismatch: the driver was pinning consumer dev-lead.yml stubs to @dev-lead/v14-<tier> (derived from the latest release tag dev-lead/v14.0.0) instead of the highest existing channel major dev-lead/v1-<tier>. The v14-<tier> channel tag does not exist, so the pin never resolved. Only dev-lead is affected — every other agent's channel-major equals its release-major.

    Plan execution

    • Derive the pin from the highest existing channel major (<agent>/v<M>-<tier>), never the release major
    • Validate the computed channel ref exists as a tag before opening a PR (assert-exists; no non-resolving pins)
    • Regression test: an agent whose release major (v14) exceeds its channel major (v1) emits v1-<tier> and resolves
    • Full suite + dev-lead-lint.sh green

    Changes

    scripts/lib/ring-pins.sh — three new helpers (release-major ring_host_current_major left untouched for migrate):

    • ring_highest_channel_major — pure; highest M among <M>-<tier> tokens, ignoring release semver
    • ring_host_current_channel_major — gh-backed channel-major from matching-refs
    • ring_tag_exists — single-ref existence probe (git/ref/tags/<ref>)

    scripts/deploy-standard-workflows.sh

    • is_already_compliant + emit_ref_for now use ring_host_current_channel_major (bare-tier grace is now keyed on the channel major)
    • deploy_repo — assert-exists guard after emit_ref_for: refuses to open a PR when the computed ref has no tag on the host

    Tests — test/scripts/lib/ring-pins.bats (unit tests for the 3 helpers) and test/scripts/deploy-standard-workflows/emit-vform.bats (2 new #870 regression tests: channel-major v1 pinned over release v14 for the live-broken bmad-bgreat-suite; assert-exists refuses a non-resolving v1-ring1). Fake-gh fixtures in emit-vform.bats, feature-ideation-seed-repin.bats, and pr-auto-review-skip-override.bats were updated from release-semver tags to channel tags to match the corrected derivation source — expected outputs unchanged.

    Verification

    Notes / scope

    • scripts/migrate-major-channels.sh — out of scope. Its create_vtags/emit_repins intentionally still use the release major (they mint the channel tags). Repointing it would be a behavior change unrelated to the pin bug.
    • scripts/compliance-audit.sh — no change needed. check_dev_lead_stub/ring_major_form_acceptable accept the consumer's own tier-correct major; they compute no expected major, so the fix is transparent to the audit.
    • AC Add coding standards & principles section to AGENTS.md #3 (correct bmad-bgreat-suite's live dev-lead.yml → dev-lead/v1-ring1) and AC Add workflow, environment, and orchestration guidance #4 (re-sweep the 5 closed repos) are operational — they land when the fixed driver runs via CI, not through code changes here.

    Per task constraints, no commits/pushes/PRs were made — the CI workflow handles git operations.

  4. don-petry
    added a commit that references this issue on Jul 22, 2026

    feat: implement issue #870 — [#850] standards-deploy driver deploys B…

    e0edcee
  5. don-petry
    closed this as completedin #871on Jul 22, 2026
  6. don-petry
    added 5 commits that reference this issue on Aug 3, 2026

    feat(#613): relocate canary-rollout engine + bootstrap into .github (…

    49c827f

    feat(audit): make centralized-stub check ring-aware (#870) (#529)

    f71c2b3

    fix: share canary-ring pin model between audit and deploy sweep (#482) (

    d3e4875

    feat(#613): relocate canary-rollout engine + bootstrap into .github (…

    bc9d0dd

    feat(#613): relocate canary-rollout engine + bootstrap into .github (…

    9d9a81b
  7. don-petry
    added 3 commits that reference this issue on Aug 31, 2026

    feat(audit): make centralized-stub check ring-aware (#870) (#529)

    9734c03

    fix: share canary-ring pin model between audit and deploy sweep (#482) (

    48769e9

    feat(#613): relocate canary-rollout engine + bootstrap into .github (…

    5f398bf
  8. don-petry
    added 3 commits that reference this issue on Sep 7, 2026

    feat(audit): make centralized-stub check ring-aware (#870) (#529)

    ba47820

    fix: share canary-ring pin model between audit and deploy sweep (#482) (

    16369ea

    feat(#613): relocate canary-rollout engine + bootstrap into .github (…

    32afd19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dev-leadFor dev-lead agent pickup

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions