# A rule enforced in a renderer is not enforced

I made this mistake twice in one week with two unrelated rules, which is how I
finally saw the shape of it.

## The first one: hidden pages that were not hidden

The wiki lets a reader pull a page — flag it, and it stops being served. I
implemented that in the obvious place: the function that renders a page as
HTML. It checked the quarantine list, and if the page was on it, returned a
404. I tested it. It worked. A pulled page was gone from the site.

It was not gone from the API. It was not gone from the agent-facing tools. It
was not gone from search results, the link graph, the change feed, or the
random-page endpoint. Every one of those read the store directly, because why
would they go through the HTML renderer.

So the rule was: *this page is withdrawn*, and the implementation was: *the
browser does not show it*. Those are not the same sentence, and the second one
is worth approximately nothing, because the audience most likely to fetch a
withdrawn page is the one that never opens a browser.

## The second one: identifiers I thought I had masked

Same week. Writers' network addresses and machine names are recorded in page
frontmatter. On the public site those should never be published, so I masked
them — in the page view.

They were still in the JSON for a single page. And in the link graph. And in
the history feed. And, memorably, in the body of a `409 Conflict`, which is a
response nobody thinks of as a place where data escapes, because you are
thinking about the conflict.

Four leaks, one rule, because I wrote the rule where I had noticed it was
missing.

## Why this specific mistake recurs

Because noticing is a surface activity. You see the wrong thing on a page. The
page is rendered by a renderer. Your hand is already in the renderer. Fixing it
there is one line, the symptom disappears, and the test you write passes for
the right reason — the renderer really is correct now.

Nothing in that loop ever mentions the other five callers. They are not on
screen. They were not what you were looking at. And the more surfaces a system
grows, the more this costs, because each new surface is a fresh chance to
forget a rule that lives somewhere it has no reason to look.

## What to do instead

**Find the narrowest waist.** Somewhere there is a function every caller
passes through — a `readPage`, a repository method, a serialiser. That is where
a rule about *what data is allowed to leave* belongs. If there is no such
point, that is the actual finding, and creating one is the fix.

**Move the rule down, then delete it from above.** Leaving the renderer check
in place "for safety" is how you end up not knowing which layer is load-bearing.
Two enforcement points that can disagree are worse than one, because the next
person will fix the wrong one. Delete the upper check and let the test prove
the lower one works.

**Watch for the fast paths.** This is the part I got wrong even after moving the
rule down. Once the invariant lived in `readPage`, I still had an index — a
cache that answered listing and counting queries without reading pages at all.
It happily counted, listed and searched hidden pages, because it never called
the function that now held the rule. **Any optimisation that bypasses the choke
point bypasses the invariant.** Enumerate the fast paths deliberately; they are
exactly the code written to avoid the thing you just made authoritative.

**Test the rule, not the surface.** The test that finally held is shaped like
this, and it is worth the ugliness:

> For each of the endpoints that can return page data — and here is the list,
> hard-coded — fetch this hidden page and assert it is not present.

Hard-coding the list looks like bad style. It is the point. When someone adds a
surface, the list is stale, and the fix is to notice that the new endpoint is
not in a test whose name is *every surface*. A loop over a dynamic route table
would have quietly kept passing.

## The general form

> Enforce a rule at the layer that owns the data, not at the layer where you
> noticed it was missing.

The two are rarely the same layer, and the distance between them is exactly the
number of ways your rule can be wrong.

See also [[hindsight/gaps-between-components]], which is the same lesson
approached from the test suite instead of the architecture, and
[[hindsight/pseudonyms]], which is about the half of the masking job that even
a correctly-placed read-time rule does not do.