Process as code

sop-slop

The quality system for a one-person workspace where several Claude Code sessions build, review and hand over work side by side.

What it is

A small Git repository of plain Markdown that every AI session reads before it plans, builds or tests anything. Sessions don't read all of it: a routing file points each one to the one or two slices its task needs.

Working rulesWho the work is for, how plans are written, how git is used. user-specs/

Best practicesOne slice each for planning, executing and testing. best-practices/

Procedures and machine specsStep-by-step SOPs, and specs of how this machine should be configured. sops/ mspecs/

Deviation registerEvery slip from any project, with its root cause and what changed because of it. deviations/

Process in proportion to risk

Every project gets a tier. The highest signal decides; checking takes about a minute.

	T1Light	T2Standard	T3Full
Which projects	Early, tiny or inactive; private	Private and active, or shared infrastructure	Public repo or website, personal data, someone else's repo, money
Branch and pull request	Direct commits are fine	Required	Required
Review before merge	—	For rule and spec changes	Always
When something slips	Fix it, say so in the commit	Note on the pull request	Note plus a register entry

In every tier: no secrets in git, no personal data anywhere public, no rewriting shared history, and nothing pushed to someone else's repo without the owner's OK. Any slip that touches those gets the full treatment, whatever the tier.

When something goes wrong

A slip is data, not a failure to hide. The register exists so that the same mistake in two different projects shows up as one pattern.

Note it at the moment. A structured DEVIATION: note on the pull request: what the procedure says, what happened, why, and what would prevent it.
File it by tier and severity. A minor slip in a low-risk project stops at the note; a recurring or serious one gets a full record.
Find the root cause. A five-why analysis, written from the artefacts, not from memory.
Fix and prevent. Corrective actions for this case; a preventive action for the next one, implemented or explicitly deferred with a reason.
Watch for recurrences. Records are grouped into clusters by root cause, and each cluster is checked at the next documentation review.

Adapted from a real record

ID WDEV-0NN Severity minor — caught in review before merge Tier T3 What A figure in a plan came from a local run that didn't match CI, which is what actually decides. Why ×5 stale dependencies → never reinstalled after the lockfile changed → no step prompts it → the figure was recorded from a proxy, not from the artefact that decides Fix reinstall; correct the figures; add a reminder Prevent check figures against CI before they go into a record

What actually holds

The most useful lesson so far: rules that depend on a session remembering them keep recurring, sometimes in the very session that wrote the rule down. Rules a script or a gate enforces hold. So the system keeps moving rules from prose into machinery.

Append-only editing. Superseded text is kept, not deleted, and a warning-only check flags any removed line that wasn't preserved. At each review, old text moves into a History section so the body stays readable.
Review before merge. In full-process projects, every pull request is reviewed at its current head before it merges. When the automated reviewer's quota runs out, another Claude session reviews instead, and the merge still waits for the owner's explicit OK.
A guard on pushes to main. A small hook is being added that asks the owner before direct pushes to the main branch, even inside chained commands, with a few standing exceptions for repositories only the owner's coordinating session writes to.
Commands tested as written. Any shell command in a document is copied out verbatim and run in two shells before it ships.