Skip to content

[bug] seed-repo-template fetches standards unpinned — pin to published stable, compliance accepts N-1 (continues #1436) #1448

Description

@don-petry

Continuation of #1436 (which shipped as #1441)

The maintainer folded the template-drift non-determinism into #1436, but that issue had already merged, so the extension is carried here to stay actionable. ACs are numbered 7–10 to continue #1436's sequence — this is the same thread of work, not a new one.

Folding the template-drift non-determinism into this issue, per the maintainer.

Decision:

  1. seed-repo-template.sh fetches standards at the latest published stable version, not the live default branch.
  2. The compliance/drift check accepts N-1 — the current published version or the one before it — so a standards promotion does not instantly fail every consumer during propagation.

The defect being fixed

scripts/seed-repo-template.sh:116 fetches unpinned:

gh api "repos/${STANDARDS_REPO}/contents/${path}" --jq '.content'   # no ?ref=

So the "expected" baseline is whatever petry-projects/.github has on its default branch at the moment of execution. The same commit therefore passes or fails depending purely on when the check runs. Demonstrated today: PR #1446's template-drift expected blob 3e2daee1f7f8 at 01:58Z; regenerating the identical SHA locally after standards moved at 02:10Z (cff381f6) produced 569270be4153. Neither is wrong — the target moved.

⚠️ Blocking prerequisite — do not pin to any existing tag

I checked every candidate ref, and none currently carries the corrected content:

candidate ref standards/workflows/dev-lead.yml
v2 (repo-level, 2026-05-19) file absent — predates the standards/workflows/ layout entirely
v1 (repo-level, 2026-05-13) file absent
pr-review-mention/v2-stable @dev-lead/stable ← legacy
feature-ideation/v1-stable @dev-lead/stable ← legacy
initiative-planner/v1-stable @dev-lead/stable ← legacy
pr-auto-review/v1-stable file absent
default HEAD @dev-lead/v1-stable ✅ (the only correct one)

Pinning to any published tag today would reintroduce the exact pre-#1184 legacy pins this issue just fixed. The repo-level v1/v2 tags are stale and predate the layout; the per-reusable channel tags version reusables, not the standards/ corpus, and happen to point at commits from before the July channel migration.

So there is currently no published version of standards/ as a corpus — that has to be created before the pin can be adopted. Implementing "pin to latest published stable" without it would silently regress the fix.

Required sequencing

  1. Establish a publication scheme for standards/ in petry-projects/.github — a corpus-level moving channel (e.g. standards/v<MAJOR>-stable) distinct from the per-reusable channels, cut from a commit that contains the corrected major-scoped pins.
  2. Then teach seed-repo-template.sh to fetch at that ref (STANDARDS_REF, defaulting to the published stable channel; STANDARDS_DIR local override retained for tests).
  3. Then teach the drift check to accept N or N-1.

Steps 2 and 3 are in this repo; step 1 is a cross-repo prerequisite in petry-projects/.github — the same standards-first ordering as #1435's original constraint and #1425's persona-schema dependency.

Updated acceptance criteria

  1. seed-repo-template.sh resolves standards content at an explicit ref (STANDARDS_REF), defaulting to the published stable channel — never an unpinned default-branch read. The resolved ref is logged, and recorded in the drift report so a mismatch is explainable rather than mysterious.
  2. The drift check treats a stub as ALIGNED if it matches the emission at either the current published version or the immediately preceding one (N-1), and says which one it matched. Matching N-1 is reported as a visible notice (propagation pending), not silently.
  3. Neither N nor N-1 may resolve to a ref carrying pre-F2: cut-release.sh learns v<major>-<tier> channels [#657] #1184 legacy channel pins — a guard or test asserts the resolved standards content uses major-scoped <name>/v<MAJOR>-<tier> refs, so this issue's fix cannot be undone by a pin.
  4. The prerequisite in step 1 is either completed or explicitly tracked before ACs 7–8 are implemented; if it is not yet available, the fetch stays on HEAD and logs the resolved commit SHA so runs remain explainable in the meantime.

AC #10 matters: it means this work delivers value (explainability) even if the cross-repo publication scheme lands later.

Activity

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

    bugBug reportsdev-leadFor dev-lead agent pickupinitiativeEpic / initiative tracking issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions