CI, local hooks, and a runtime-owned write path can all run checks against code. That surface similarity hides a more important difference: they sit at different points in the mutation path and answer different questions.
Tsqoba uses all three ideas where they fit. The useful current distinction is not that one tool is "the real one" and the others are obsolete. The distinction is narrower. Each layer changes a different part of the workflow.
What CI is good at
CI is good at broader or heavier checks. It can build more, run more, look across more files, and use more time than a fast write-path check should spend.
That also means CI usually arrives later. By the time CI speaks, the candidate change already exists as a patch, branch, or review object. That is often exactly right. Some questions only make sense once the fuller candidate state exists.
What local hooks are good at
Local hooks are good at fast author feedback. They help one workstation catch formatting issues, obvious lint errors, or small repository conventions before the author moves further.
That is useful, but it is still a workstation-local layer. Even when teams distribute the same hook set, the author tool is still attempting the write and the local environment is still part of the path. That is not the same as a runtime-owned acceptance lane.
What changes when the runtime owns the write
An owned write path changes something more basic. On that lane, the runtime is the writer. The candidate change stays provisional until the runtime accepts it. If a pre-write rule blocks, the write never lands on that path and the workspace stays unchanged.
That is the current shape on Tsqoba's owned patch lane. Musha is the repo runtime on that path. Sadave is the write-time policy layer that evaluates the candidate file set before patch apply runs.
// simplified current order on the owned patch lane run_fs_write_pre_hooks(..., &req.action).await?; let result = apply_patch_in_dir(...);
The important point is not the component names. It is the sequence. The runtime decides whether the write gets to happen on the lane it already owns.
Why the distinction matters
Some mistakes are cheap to classify from one file plus repository policy and expensive once they become accepted local style. Direct repo-config access, panic shortcuts in shared Rust code, sleep-based timing in tests, and serial escape hatches all fall into that bucket on current Tsqoba paths.
CI could still catch some of those later. A local hook could still warn about some of them earlier. But those are different social and technical outcomes.
A late CI failure arrives after the shortcut has already been written, explained, and partially normalized. A local hook warning still depends on one author machine and one author tool path. An owned write path changes the acceptance step itself. The shortcut never becomes accepted code on that lane.
These layers complement each other
The current claim is narrow. Tsqoba does not argue that CI should disappear or that local hooks are useless. It argues for a clearer split of jobs.
Use an owned write path for cheap, file-local, already-known bad patterns on paths the runtime already controls. Use CI or later checks for broader, heavier, or more semantic work. Use local hooks for fast author ergonomics where they help.
Those layers can share rule logic and still be doing different jobs. The key question is not "where else could this rule run?" The key question is "who owns the write, and what changes once rejection happens at that point?"