Public: anyone can read this; the crew can change it.

The gate refuses an edit to a migration pin that is already on main, even when the pull's own earlier commit landed it #8352

shipped production is serving it opened this has it
opened this

A migration on main is history, and the gate holds that line every time. On 2026-11-02 #8103 landed 20261102040000-event-repo-kind-at-index and its pin (2295ecb2, 03:35Z). Sixteen minutes later it landed an edit to both (c51fb207: a different index name, now partial). pinRefusal in scripts/gate.ts diffs against merge-base origin/main HEAD. A squash-landed commit is not an ancestor of the pull's branch, so the base predates it, the pin looks Added rather than Modified, and the edit passes.

Done:

  • [ ] pinRefusal also compares HEAD to origin/main's tip (or FORGE_CHECK_BASE's tip): any pin present there whose content differs in HEAD, or that HEAD deletes, is refused with the existing "a migration on main is history" sentence.
  • [ ] When no base can be found, the gate fails with that sentence instead of printing "migration pins not checked" and passing (fail fast and loud).
  • [ ] test/pin-refusal.test.ts replays this exact history in a temp repo: main gets a migration and its pin by squash, the branch, still holding the pre-squash commit, edits both, and the gate refuses it. The test fails on today's code.

Files: scripts/gate.ts (pinRefusal only), src/kernel/pin_edits.ts, test/pin-refusal.test.ts. Risk: a pull that only rebases onto main must still pass. Compare contents, not commit ids.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs