# Hooks are kernel code: what changed in v1.3.0, sgit.ai > The changes to the article "Hooks are kernel code" in v1.3.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Hooks are kernel code](../../hooks-are-kernel-code.md) / [Versions](../hooks-are-kernel-code.md) / v1.3.0 # Hooks are kernel code: what changed in v1.3.0 From v1.2.0 (2026-10-16, `62d7d61bb`) to v1.3.0 (2026-10-18, `de821285d`), paragraph by paragraph. 0 paragraphs added, 0 removed, 4 changed in place, 54 unchanged. About 0 words added and 12 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [← v1.2.0](v1.2.0.md) · [all versions](../hooks-are-kernel-code.md) 1 unchanged paragraph Summary: The hooks we are now going to deploy are code, and very critical code. They are also a very good example of code that is simple in many ways: a hook can be five lines. That makes them theabestgood case study I can think of for everything we do on code review, code practices, semantic graphs and change blast radius, because the problem is small enough to do completely. A hook runs on every matching action, with the user's permissions, and can see, block or rewrite what the agent does; we should treat it like kernel code. Hooks also range from completely deterministic scripts to hooks that call a model or a whole agent, so I propose a maturity model: five levels from the prompt to off the machine, and three questions for every hook, how much power it has, which legs of the lethal trifecta it touches, and how much sandbox it runs in. I mapped the first ten: three this session runs, five tested in a sandbox, two proposed. They are between 4 and 26 lines, and the smallest of them depend on much more: the eleven-line commit hook calls a 37-line scan, so one line changed in the scan moves the commit gate for every session. And this is a brief for a site and a feed to manage them, like a skills manager: every hook from its intent, with its graph, tests, version and signature, installable anywhere, and a billing model where nobody pays to run a hook, but paying buys state. 3 unchanged paragraphs, under In short {#in-short} • **The**Abestgood case study we have.**study.** Small enough to apply code review, graphs and change blast radius completely. 10 unchanged paragraphs, under Kernel code {#kernel} ## TheAbestgood case study we have {#case-study} They are also theabestgood case study I can think of for the way we want to do code review. The work on [code review as a fractal semantic graph](../../code-review-as-a-fractal-semantic-graph.md), which started at [secrets.sgit.ai](https://secrets.sgit.ai/) in its [review graphs](https://secrets.sgit.ai/review/), draws a change from the method it touched up to the stories that can reach it. On a large codebase that graph is big. A hook can be five lines. The whole graph, from the intent it serves to every line it runs and everything it calls, fits on one page, so we can do all of it, completely, and show it working. 40 unchanged paragraphs, under Hooks of hooks {#fractal}, A maturity model {#maturity}, Where hooks run {#where}… [← v1.2.0](v1.2.0.md) · [all versions](../hooks-are-kernel-code.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/hooks-are-kernel-code/v1.3.0.html)*