---
name: bless-env-turns-a-drift-gate-into-a-write
description: "A regenerate/bless env var (SPT_BLESS=1) makes a snapshot drift test WRITE the file and return early — so any mutation arm run with it set silently self-heals and reports GREEN. Clear the bless var before measuring a snapshot gate's discrimination."
metadata: 
  node_type: memory
  type: project
  originSessionId: d3652482-14ed-4c90-b240-4f6cc2208e8d
  modified: 2026-08-04T03:35:33.774Z
---

**`SPT_BLESS=1` does not just regenerate — it turns the drift gate into a no-op that
rewrites its own subject.** `checked_in_schema_is_current`
(`crates/spt-runtime/src/manifest.rs`) reads the var FIRST, writes
`manifest.schema.json` from the derives, and `return`s before it ever compares. Every
other memory here records `SPT_BLESS` as the REGENERATION RECIPE
([[m11-w3-progress]], [[v0160-w1-manifest-runtime]], [[v0143-raw-inject-removal]]);
none records it as a MEASUREMENT hazard, which is the half that bites.

**Why:** a mutation proof asks "does this gate discriminate?" With the bless var live
in the environment, the mutation arm plants a defect, the test overwrites the planted
file, and the run reports PASS — a GREEN that means the instrument healed the defect,
not that the defect was absent. Same family as [[zero-match-filter-reads-as-absent]]
and [[render-not-read-pipefail]]: a green-looking result where the assertion never ran.
It is worse than a skipped step, because the arm also DESTROYS the mutation, so a
later `git status` looks clean and nothing survives to show the arm was void.

**How to apply:** before measuring any snapshot/drift gate, print the bless var and say
out loud that it is unset — do not assume an inherited agent environment is clean.
Measured 2026-08-03 on hfenduleam at 11169c1: `SPT_BLESS`, `CARGO_TARGET_DIR` and
`SPT_POOL_UNCHECKED` all confirmed empty BEFORE arm 0, which is why the four arms
(baseline PASS / one semantic byte RED at `manifest.rs:2374` / whitespace-only PASS /
post-restore PASS) carry any weight at all. Generalise past this one var: any
`*_BLESS` / `*_UPDATE` / `UPDATE_SNAPSHOTS` / `INSTA_FORCE_UPDATE` style knob converts
the assertion it guards into a writer, so it belongs on the pre-flight checklist of
every mutation proof, not just this test's.

**Second property, same test, worth keeping:** the checked-in file is CRLF on disk while
the generated string is LF, and the test compares `got.replace("\r\n", "\n")` against
`want`. So the UNMUTATED baseline passing IS the proof the normalisation is
load-bearing — strip the normalise and the baseline reds with no mutation at all. A
whitespace-only arm (CRLF→LF, 1014 endings, 45304→44290 bytes) then shows the tolerance
runs both spellings. Related: [[make-a-new-rig-red-on-purpose]],
[[probe-an-unmodified-subject-needs-no-baseline]],
[[verify-the-subject-not-just-the-measurement]].


---

⭐⭐ **THE OTHER FACE, 2026-08-27 (todlando, IO-PARSER W3): how this gate FINDS you, and why no
targeted leg can.** The entry above is about measuring the gate; this is about tripping it.

Adding one struct (`Io`) to `crates/spt-runtime/src/manifest.rs` — a new `[io]` manifest section —
silently drifted `manifest.schema.json`, because the schema is DERIVED from those types and
CHECKED IN. Nothing about the change looked schema-shaped: I added a struct, a field, a helper and
four units, and ran targeted legs for every one of them.

**Every targeted leg was green while the drift stood.** Grammar units green, gate units green,
store units green, the crate's own filtered `-E 'test(io_gate)'` leg green — because the drift
test is a DIFFERENT test in the same crate, and a filter that names your new tests excludes the
one your change actually broke. The red appeared only in the crate-wide sweep, at
`1953 tests run: 1952 passed, 1 failed`, and it named its own remedy (`SPT_BLESS=1`).

**The rule, and it generalises past this file:** targeted legs test WHAT YOU CHANGED; a crate-wide
sweep tests what your change TOUCHED. Any repo carrying a derived artifact under version control —
a JSON schema from derives, a CLI reference from `--help`, a golden snapshot — has at least one
test that is invisible to every filter you would think to write, because you filter on the names of
things you added. If a change touches a type that any generator reads, run the OWNING CRATE'S full
suite before believing a green.

Cheap detector when you cannot afford the sweep: `git status` after a `--bins`/full build often
shows the regenerated artifact as modified. Cheaper still: ask "does anything GENERATE from this
type?" before filtering. Kin: [[cli-command-docs-drift]] (the `xtask check` face of the same
class — my W1 lane tripped that one for exactly the same reason, two new CLI flags).