Repository navigation
e-pin the estate reusables to the last accepted standards ref - #550
Merged
Merged
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.
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
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. Comment |
7 of 13 tasks
hyperpolymath
added a commit
that referenced
this pull request
Oct 7, 2026
<!-- SPDX-License-Identifier: CC-BY-SA-4.0 Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk> --> ## Summary This PR is a rescue of the D37 phase-zero recovery commit `632b54a` (2026-08-24), rebuilt as the single commit `d19776e` on `main` (the original commit left the branch so GitGuardian no longer sees its test-canary password; kept locally in `refs/rescued/pr596/`). `main` had independently landed most of the original work, so every one of the 33 conflicts resolves to `main`'s version: - the pin, `actions.lock` and permissions edits (#550–#566, #594); - the `fixer.rs` restoration. At the old base that file was a 14-line malformed patch fragment; `76ac79d` onward restored it; - the `hypatia.rs` `?` refactor; - the `6a2/` → `descriptiles/` move. A2ML is retired, so it is not re-homed; - the echidnabot `api.adoc` deletion (#586). Net change against `main`, 3 files: 1. **`repo-integrity-guard.yml`**: a new step, *Source files must not be patch fragments*. It fails when a tracked `*.rs/ex/exs/res/js/ts/py/sh` file starts with `@@ `, `*** Begin Patch` or `diff --git`. That is exactly how `fixer.rs` was broken. 2. **`.gitignore`**: ignores `.claude/worktrees/`, so an agent worktree can't be committed as a gitlink again. That had happened with `actions-policy`, which `main` has since dropped. 3. **`SECURITY.md`**: adds reporting expectations (acknowledgement within 48 hours, assessment within 7 days, 90-day coordinated disclosure), a supported-versions statement and a safe-harbour clause. It keeps `main`'s pointer to `SECURITY.adoc`, which has none of these. Closes: none ## Type of change - [ ] 🐛 Bug fix (non-breaking change that fixes an issue). The breakage is already fixed on `main`. - [ ] ✨ New feature (non-breaking change that adds functionality) - [ ] 💥 Breaking change (would change existing behaviour) - [x] 🕳️ Soundness fix (fixes a checker/proof false-negative). The integrity guard did not catch a source file that was a patch fragment. - [x] 📖 Documentation (`SECURITY.md`) - [ ] 🧹 Refactor / tech debt (behaviour-preserving) - [ ] ⚡ Performance - [x] 🔧 Build / CI / tooling ## 📌 New pins Head SHA: **`d19776e`**. This PR adds or changes no pins. Every `uses:` ref and `actions.lock` entry is `main`'s, byte for byte. ## How has this been verified? - `git diff --stat origin/main d19776e` shows 3 files changed, +41/−10, and nothing else. - I ran the new guard's script locally on the merged tree: rc=0, no findings. - Positive control: I planted `planted_frag.rs` starting with `@@ -1,2 +1,2 @@` and staged it with intent-to-add. The guard reported `::error file=planted_frag.rs::Source file begins with patch syntax` with rc=1. The planted file was then removed. - `actionlint .github/workflows/repo-integrity-guard.yml` was clean. - `grep` of `SECURITY.adoc` for hour/day/harbour/disclosure/acknowledge found nothing, so the `SECURITY.md` additions are not duplicates. ## Checklist - [x] My commits are **signed** (`git commit -S`). `d19776e` shows `G`. - [ ] I ran the project's own checks/tests locally and they pass. No Rust source changed against `main`. The repo's CI on `d19776e` is the check, and I ran the guard step locally (above). - [x] New files carry the correct `SPDX-License-Identifier`. There are no new files; `SECURITY.md` keeps its existing `MPL-2.0` header. - [x] Docs are updated, and no public claim now overstates what the code does. - [x] I have not introduced a soundness hole. The guard only adds a failure path. ## Notes for reviewers - The guard checks only the *first non-blank line* of each file. A fragment that is spliced into the middle of a file is out of its scope. - The `SECURITY.md` response-time commitments are the owner's text from `632b54a`, kept verbatim. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_014BxjiTAaTZCHVWn2U5NWhL Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.