forked from mosaicstack/stack
Registered at head83d2ecb2before dispatch. Prior reviews 63/65 are superseded and this head carries no live review of any kind, so the keystone gets a full independent review. The crux is the one non-mechanical change, which f10-coder disclosed unprompted: activationCommit advancedf65e9ea6->f4fd5967so that the newly merged pre-registry RM-61 commit is no longer treated as prospective. activationCommit sets the lower bound of the commit range required to carry own-tree registry provenance, so advancing it SHRINKS that set. The value is plausibly correct — a pre-registry commit cannot carry a registry manifest — but the change was made by the author to turn the author's own gate from red to green, which is the self-verification shape the charter warns about. Registered as A1-A6 without a verdict from me (D-39). A4 is the sharp one: the only validation on the field is merge-base --is-ancestor activationCommit head, and a commit is its own ancestor, so setting activationCommit = HEAD would empty the prospective range and the per-commit provenance loop would iterate zero times. Whether that makes the history check pass VACUOUSLY is for rev-974 to determine and report — an author-settable field that can inert the anti-inert-gate registry's own history check would be the disease inside the cure again. A5 asks whether a must-fail negative control exists for it, since RM-02's own founding rule is that a gate with no proven failure path manufactures evidence. B1/B2 carry Mos's scope ruling that the D-38 bind-to-subject and D-40 type-strict clauses land in THIS PR; B3 confirms D-42's clause is deliberately absent rather than forgotten. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>