File writes are checked before patch apply

On the owned patch lane, a file change stays provisional until `fs.write.pre` accepts it. The useful fact is order: hook first, patch apply second.

File writes are checked before patch apply

On the current owned patch lane, a file change stays provisional until fs.write.pre accepts it. The key fact is simple: the hook runs before patch apply. A proposed patch becomes a real write only after the hook accepts it.

Musha is the repo runtime on that lane. Sadave is the write-time policy layer it calls before patch apply. The names matter less than the sequence.

Order first

On the current Musha path, the sequence is straightforward: derive the patch action, run pre-write hooks, then call the canonical patch adapter only if the hook path accepts the proposal.

RUST
run_fs_write_pre_hooks(..., &req.action).await?;
let result = apply_patch_in_dir(...);

The runtime is not cleaning up after a write. It is deciding whether the write gets to happen on that owned path at all.

That distinction matters because the repository never briefly enters the rejected state and then tries to recover. The block happens before the tree changes.

What the hook actually inspects

The hook does not pretend to run full-repository semantic review before every patch. It derives targeted files from ApplyPatchAction, sorts them deterministically, and evaluates candidate bytes with base-workspace context.

That keeps the lane narrow and cheap enough for the job it is trying to do. It does not try to answer every possible question about the patch. It stops one class of already-known bad local writes before they become accepted code.

What happens on block

If one targeted file blocks, patch apply never runs for that proposal. The workspace stays unchanged, and the reject is recorded as a typed result rather than an unstructured red line.

That gives the author a clearer next move. The runtime can name the rule, the file, and the immediate remediation path while the patch is still provisional.

Why the typed trail matters

A typed reject is not just a nicer error message. It makes the stop reviewable. Later readers can see which rule fired, what surface emitted it, and what concrete write was refused.

That is useful because the current write lane is not the whole product story. Tsqoba also uses later checks, replay surfaces, and retained artifacts. But on this particular lane, the smallest reliable claim is already enough: a write stays provisional until the owned pre-write path accepts it.

Contents
  1. Order first
  2. What the hook actually inspects
  3. What happens on block
  4. Why the typed trail matters