Skip to content

blog: the control that could not fail - #868

Merged
gHashTag merged 2 commits into
mainfrom
blog/control-that-could-not-fail
Aug 22, 2026
Merged

blog: the control that could not fail#868
gHashTag merged 2 commits into
mainfrom
blog/control-that-could-not-fail

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Eighth post of the gate-audit campaign, and the first where the defect was in the instrument I had just built.

Four gates had no negative control. Writing them produced thirty-one killed mutants — and one control that could not fail: it called the checking function directly, so with main()'s return 1 changed to return 0 the gate printed OK on a catalog with a dangling reference and all seven cases still reported "RED, correct branch".

The post argues the in-process design was not the mistake — it exists because a control run from the wrong directory once resolved its root to / and nearly reversed a conclusion — and that the fix is a layer added, not replaced.

It also carries the distinction the follow-up report turns on: nine gates with surviving mutants is nine controls that do not reach far enough, not nine broken gates. All six baseline-backed gates were checked by hand and go red correctly today.

en + ru. build:ci clean, tsc clean on the blog data.

Refs gHashTag/t27#2465, gHashTag/t27#2467, gHashTag/t27#2468

Four gates had never been seen red. Writing their negative controls turned
up one that certified the checking function but not the wiring from that
function to the exit code -- so with main() neutered the gate printed OK on
a broken catalog while its control reported every branch red.

Also: my first attempt to measure this rewrote the returns inside the
controls too, which made two sound controls look like vacuous passes. And
the distinction the report turns on -- nine surviving mutants means nine
controls that do not reach far enough, not nine broken gates. All six
baseline-backed gates were checked by hand and are correct today.

Refs gHashTag/t27#2465, #2467, #2468
PostMeta requires openQuestions and published; the new entry had neither,
and typecheck:ratchet caught it as src/data/blog/index.ts: 0 -> 1.

My own tsc check had missed it because I ran it from the repository root
rather than apps/website, where that tsconfig lives -- the same
wrong-working-directory error the post this entry describes is about,
made while adding the post.

Two unrelated things in the same commit, both stated rather than quiet:

  - .claude/launch.json was created by the preview tooling and committed
    by accident. It is not on main. Removed.
  - typecheck-baseline.json 184/27 -> 179/26. The improvement is NOT mine
    (SacredChemistryWidget.tsx, 5 -> 0, already improved on main, where
    this gate is red for the same reason). Locking it in is the downward
    direction and stops the gain sliding back unrecorded.
@gHashTag
gHashTag merged commit 3a7f7e0 into main Aug 22, 2026
14 of 17 checks passed
@gHashTag
gHashTag deleted the blog/control-that-could-not-fail branch August 22, 2026 21:41
github-actions Bot added a commit that referenced this pull request Aug 22, 2026
blog: the control that could not fail (#868)

* blog: the control that could not fail

Four gates had never been seen red. Writing their negative controls turned
up one that certified the checking function but not the wiring from that
function to the exit code -- so with main() neutered the gate printed OK on
a broken catalog while its control reported every branch red.

Also: my first attempt to measure this rewrote the returns inside the
controls too, which made two sound controls look like vacuous passes. And
the distinction the report turns on -- nine surviving mutants means nine
controls that do not reach far enough, not nine broken gates. All six
baseline-backed gates were checked by hand and are correct today.

Refs gHashTag/t27#2465, #2467, #2468

* fix(blog): the index entry was missing two required fields

PostMeta requires openQuestions and published; the new entry had neither,
and typecheck:ratchet caught it as src/data/blog/index.ts: 0 -> 1.

My own tsc check had missed it because I ran it from the repository root
rather than apps/website, where that tsconfig lives -- the same
wrong-working-directory error the post this entry describes is about,
made while adding the post.

Two unrelated things in the same commit, both stated rather than quiet:

  - .claude/launch.json was created by the preview tooling and committed
    by accident. It is not on main. Removed.
  - typecheck-baseline.json 184/27 -> 179/26. The improvement is NOT mine
    (SacredChemistryWidget.tsx, 5 -> 0, already improved on main, where
    this gate is red for the same reason). Locking it in is the downward
    direction and stops the gain sliding back unrecorded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant