A coding agent followed the pointer to its rules file in 4 of 81 sessions

Enforcement happens at two points and only two: the agent host can run a hook right before a tool call executes, and another when the model finishes its turn. Either one can refuse and make the model try again ^[7]. Load order does not reach either point. Both designs the author tried, pointers fetched on demand and every rule always resident, put text into the context window, and neither could stop an action once the model had ignored the rule ^[23].

The framing in the write-up is that most tooling in this space is about retrieval, getting the right text in front of the model, and that retrieval mostly works ^[3]. It did work here. Three notes describing the heredoc mistake had all been retrieved and read before the agent made it again ^[2].

The 4.9 percent belongs to one host ^[4]. Under a different host the same pointer file was opened in 109 of 144 sessions, about 76 percent, with 96 of those openings inside the first three actions ^[8][9]. The second host opened it roughly fifteen times as often ^[10]. The author's explanation is a default: that host reads the whole rules file at the start of every session, so it never has to follow the trigger ^[8]. For the 4.9 percent to describe your stack, your host would have to leave rule files unread until something in context tells the model to open them.

A hook can only refuse what it can see from outside the model. "Don't write files through a heredoc" is checkable, because the command string contains << and a backslash ^[12]. "Verify before you say it's done" happens inside the model, where nothing outside can see it ^[12]. So the author changed the rule. A message claiming something is done now has to name what was checked, such as a test count, a command, or a file that was read. An end-of-turn hook can refuse the message when it does not ^[13]. Skipping verification used to leave no trace, and the only route past the new check is to write down evidence that does not exist ^[14].

Then the checks failed quietly. A per-turn cap on how many rule files get read was there for speed. It bounded enforcement as well as discovery: in one large store, 500 armed rules came out as 12 live per turn, or 2.4 percent ^[18][19]. Saving a note made the memory store reformat metadata and nest the fields one level down, and the checker read top-level fields only, so those rules passed lint and blocked nothing ^[20]. One rule guarded a tool named Bash; another host calls its shell tool Shell, the comparison was exact, and the rule never fired there ^[17]. The end-of-turn check read only the final message, which put a false claim made before a tool call out of reach of every rule ^[15]. That one surfaced when the agent said something had never been tested. It had been tested the day before, the work had been summarised out of its context, and the agent read "I can't see it" as "it didn't happen" ^[16].

The fifth was the tuner. Logic that relaxed rules which fired too often switched off a rule for two weeks after it fired six times and blocked all six. A hit rate cannot separate "too broad" from "the agent keeps doing this" ^[21]. The author removed the tuning ^[21]. None of the five raised an error ^[22].