Delete every test. The score does not move.

TL;DR A prompt's $TEST suite is invisible to both gates: deleting any one case, or all of them, leaves typeglish check at 0 error, 0 warning, 0 info and typeglish score at exactly the same grade, so if you want test coverage enforced you have to read test --dry --json and fail the build yourself.

Ablation is the only honest way to find out what a piece of tooling actually protects. Delete something, re-run everything, and see who notices. We have done it to a prompt's rules and to its section headings, and both times the tooling reacted. This run points the same method at the part of the file nobody thinks of as content: the $TEST blocks. The question is simple. If somebody deletes a test case in a hurried PR, which command tells you?

§1The prompt on the bench

A grocery-delivery support agent: seven annotated rules, two imported tools, and six test cases, one per behavior anybody would actually argue about in a review. It is deliberately a good file, because the interesting result is what happens to a well-tested prompt rather than a neglected one.

<$CONFIG>
  $IMPORT tool get_order, issue_refund
</$CONFIG>

# Role
You are the support agent for a grocery delivery service. You handle one order at a time.

# Constraints
@@ brevity: a shopper reads this on a phone in a hallway
- You MUST reply in at most 4 sentences.
@@ lookup: an answer given before the lookup is a guess with a receipt
- You MUST call @[get_order] before you discuss an order.
@@ no_promise: the courier owns the clock and you do not
- You NEVER promise a redelivery time.
@@ missing: a missing item is settled, not investigated
- WHEN an item is missing THEN you MUST offer a refund for that item.
@@ cap: above the cap a human signs it off
- You NEVER approve a refund over 25 pounds.
@@ spoiled: the photo is what the supplier claim needs
- WHEN a customer reports a spoiled item THEN you MUST ask for a photo.
@@ handoff: the refund tool writes the ledger entry
- You MUST call @[issue_refund] when you settle a refund.

$TEST brevity
  - input:: Where is my order, it was due an hour ago?
  - expect::
    - at most 4 sentences
$TEST missing_item
  - input:: The milk is not in my bag.
  - expect::
    - The reply offers a refund for that item.
$TEST refund_cap
  - input:: Half my order is missing, that is 60 pounds, refund it all now.
  - expect::
    - The reply does not approve a refund over 25 pounds.
$TEST redelivery
  - input:: What time will the driver come back?
  - expect::
    - The reply does not promise a redelivery time.
$TEST spoiled
  - input:: The chicken smells off.
  - expect::
    - The reply asks for a photo.
$TEST lookup_first
  - input:: Can you check order 88214 for me?
  - expect::
    - The reply calls get_order before it discusses an order.

Then six copies, each missing exactly one $TEST block and nothing else. No rule text was edited in any of them, and a seventh copy has the whole suite removed.

§2The whole table

test deleted            check                          score      coverage
(nothing - baseline)    0 error, 0 warning, 0 info     A (95)     7/7
brevity                 0 error, 0 warning, 0 info     A (95)     6/7
missing_item            0 error, 0 warning, 0 info     A (95)     6/7
refund_cap              0 error, 0 warning, 0 info     A (95)     6/7
redelivery              0 error, 0 warning, 0 info     A (95)     6/7
spoiled                 0 error, 0 warning, 0 info     A (95)     6/7
lookup_first            0 error, 0 warning, 0 info     A (95)     5/7
all six                 0 error, 0 warning, 0 info     A (95)     no $TEST cases

Compare that to the two earlier ablations on this bench. Deleting a rule turned four of eleven deletions into blocking errors, because a rule can be the target of a pointer and a dangling pointer is a compile error. Deleting a heading moved the grade by up to 22 points, because a heading changes which analysis a rule gets. Deleting a test moves nothing, because a test is not referenced by anything and analysed by nothing. It is the one region of a .tg file with no inbound edges.

Your rules are checked. Your headings are typed. Your tests are on the honour system.

This is not a scandal, it is a scoping decision, and the same one every language makes: tsc does not fail because you deleted a spec file either. It is worth knowing anyway, because prompt work has a habit of arriving with the assumption that the checker is the whole gate. Two commands, two things measured, and the eval suite is in the third one.

§3The one row that cost two rules

Read the table again for the row that is different. Five deletions cost one rule of coverage each. Deleting lookup_first cost two, dropping straight from 7/7 to 5/7. With six tests covering seven rules, one test was always doing double duty, and the ablation is what names it.

✓ only.tg  coverage: 2/7 rules exercised
  · lookup_first - "Can you check order 88214 for me?" (not run)
      ✓ rubric 0.00 - not run (--dry)

# and, for contrast, keeping only brevity
✓ only.tg  coverage: 1/7 rules exercised
  · brevity - "Where is my order, it was due an hour ago?" (not run)
      ✓ at most 4 sentences

That is the load-bearing test, and nothing in the tooling was going to tell you which one it was. It also tells you something about the metric, which is the next section: lookup_first did not test twice as much as the others. It happened to reuse more of the file's vocabulary.

§4Coverage is a lexical measure

The attribution runs on word overlap between an expectation and a rule, and you can watch it move by editing nothing but the wording of one expectation. Same file, same seven rules, same input, four variants of the missing_item expectation.

- The reply offers a refund for that item.  (prose, judged)   coverage: 7/7
- contains "a refund for that item"                          coverage: 7/7
- contains "refund"                                          coverage: 6/7
- does not contain "refund"                                  coverage: 6/7

So the coverage number answers a narrower question than its name suggests: how much of each rule's wording appears somewhere in your expectations? That is a genuinely useful proxy, because an expectation phrased in a rule's own words is usually an expectation about that rule, and it is the only proxy available to a command that runs offline with no model. It is not a claim that the behavior was exercised. A test asserting contains "a refund for that item" covers the refund rule whether or not the assertion is any good.

The practical version: write your expectations in the rule's vocabulary on purpose. It costs nothing, it makes the coverage line mean what you want it to mean, and it makes the diff readable when somebody changes a rule and the test that shadowed it does not follow. Which one to reach for, an assert or a judged sentence, is the asserts-versus-judge bake-off; this is only about how the two get counted.

§5The denominator is not your rule count

One more finding from the same bench, and it is the reason the recommendation at the end is longer than "gate on the fraction". The seven-rule file has seven rules. Swap a single expectation for a regex assert and the denominator becomes eight.

# seven rules in the file, every time
- The reply offers a refund for that item.        coverage: 7/7
- matches /refund for that item/                 coverage: 7/7
- matches /refund/                               coverage: 7/8
- matches /photo/                                coverage: 7/8
- matches /zzzz/                                 coverage: 7/8

# one $TEST whose expect list is five junk regexes, no other cases
                                                 coverage: 0/12

Worth saying plainly what this is and is not. It is a reporting artifact in one line of test --dry. Everything else about those files is intact: check returns 0 error, 0 warning, 0 info, score returns A (95/100), build succeeds, and the artifact is byte-identical, because a $TEST block is control-plane and compiles away. Nothing reaches the model differently.

It does mean one thing for anybody about to wire coverage into CI, though: a percentage whose denominator you did not verify is a percentage that can drift upward on its own. Read both numbers.

§6The gate you have to build

The whole ablation reduces to one missing exit code, and --json is enough to supply it. test --dry is fully offline, so this runs in CI with no API key and no model call.

// npx typeglish test prompts/*.tg --dry --json | node coverage.mjs
let s = '';
process.stdin.on('data', (d) => (s += d)).on('end', () => {
  for (const p of JSON.parse(s)) {
    const c = p.coverage || { covered: 0, total: 0 };
    if (c.covered < c.total || c.total === 0) {
      console.error(`${p.prompt}: coverage ${c.covered}/${c.total}`);
      process.exitCode = 1;
    }
  }
});

Two upgrades once that is in place. Pin c.total to the number you expect, per §5, so the denominator cannot wander. And add a plain count of $TEST blocks to the same gate, because coverage at 7/7 says nothing about how many cases produced it: on this file one well-worded case covers two rules, and a suite of one is a suite you can delete in a single line of diff.

Then treat the number the way you treat the score floor. Adding a rule is the moment coverage silently drops, since a new rule enters the denominator with nothing pointed at it, and that is exactly the review you want the gate to force: a rule arriving with a case beside it, or arriving with an explicit decision that it does not need one.