e-pin the estate reusables to the last accepted standards ref - #751
Conversation
Pins at `4e6ffe55`-or-later are rejected by GitHub's dependency-lockfile validation, so the callers that used them could not parse: `conclusion=failure`, **0 jobs**, run name equal to the file's path. `210f14e7` (2026-09-12T17:32:17Z) is the last ref whose pins are accepted — measured by pinning a caller at each candidate and dispatching it, not inferred. This re-points the refs here to that ref. Behaviour is otherwise unchanged; the lockfile in `hyperpolymath/standards` is the thing that has to be regenerated before a forward re-point is safe again, and the estate's own applier (`.github/workflows/apply-workflow-pins.yml`) is what should do that re-pointing once it can run.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (5)
🔇 Additional comments (1)
📝 SummarySummary by CodeRabbit
WalkthroughThe governance workflow comment now references a pinned reusable workflow commit instead of ChangesGovernance reference
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Change: Other Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. A rabbit checks the pinned trail Comment |
|



fix(ci): re-pin the estate reusables to the last accepted standards ref
Pins at
4e6ffe55-or-later are rejected by GitHub's dependency-lockfile validation, so thecallers that used them could not parse:
conclusion=failure, 0 jobs, run name equal to thefile's path.
210f14e7(2026-09-12T17:32:17Z) is the last ref whose pins are accepted — measured bypinning a caller at each candidate and dispatching it, not inferred.
This re-points the refs here to that ref. Behaviour is otherwise unchanged; the lockfile in
hyperpolymath/standardsis the thing that has to be regenerated before a forward re-point is safeagain, and the estate's own applier (
.github/workflows/apply-workflow-pins.yml) is what should dothat re-pointing once it can run.