Every project leaves a stone for the next one.

1. Stone 5 · capstone

   Session rules

   Five rule files Claude Code loads from the installed release. Two load in every session: working from a brief, and running shell commands. Three load when a task calls for them: changing a gate, stamping a record with the time, and closing a session.

   More on the rules

   • The rules load once per machine, from the one release that machine's setup names. A project's pin picks the code it runs, never the rules.
   • A daily load check reads each session's own record of what it loaded, and raises an alert when a session that loaded the machine's setup missed a rule file it imports, or when no session on a Claude Code version loaded the setup at all.
   • A closing routine has a session bring its records up to date and write a handoff before it ends, so the next session starts from what's known.
   • Claims that something is absent need proof: a search whose exit status shows nothing matched, run in a form that reads every byte of every file.
2. Stone 4 · CI on the remote

   Checks

   Once a project has a remote, CI scans again where the code lands: the whole tree for credential shapes, plus a marker scan that names no one. It runs even when a local hook was skipped. Your identity list stays on your machine: CI only ever gets terms that identify no one.

3. Stone 3 · commit and push hooks

   Guards

   Every commit is scanned for credentials, and every push for credentials and your own identity terms: in files, in binaries, and in commit and tag metadata. The first commit waits for the stakes frame. When a hook can't run its checks, it refuses.

   What each hook checks

   At commit

   • Credentials in what's staged, with gitleaks.
   • A placeholder author email is refused.
   • A project's first commit waits until its stakes frame is filled in.

   At push

   • Credentials, again, in the commits the push adds.
   • Your identity terms in every file of the tree at each tip you push, every line read as text whatever bytes it holds.
   • Images and video pass only once reviewed, and only if they carry no metadata.
   • Author, committer and message on every commit and tag, read without git's name-rewriting file, so a .mailmap can't mask a name.

   When something is wrong

   • No gitleaks, no identity list, or a list that doesn't match its pinned hash: the push is refused.
   • Python runs isolated, so a module planted on your path can't run inside a check.
   • A check that can't run counts as a failure, never as a pass.
4. Stone 2 · starting points

   Patterns

   Copy-paste starting points with the safeguard already built in, each naming the failure it prevents.

   • dry-run gated runner
   • atomic deploy
   • counted-skip loader
   • repo genesis
   • local spawn
   • local upgrade
   • numbered relays
5. Stone 1 · foundation

   Records

   Four logs, numbered and append-only: decisions with their reasons and the alternatives that lost; incidents with how each fix was verified; a follow-up queue sorted by what happens if an item never gets done; and kit feedback, written at the moment of friction. Corrections are dated notes, never quiet edits.

How it runs

Pinned, not copied.

Through v0.7.0 the kit was copied into every project, and the copies drifted apart. Since v0.8.0, each release installs once and each project points at the one it runs.

~/.local/share/morrowcairn/releases/
└── v0.10.0/         read-only, every file hashed

your-project/
├── kit.pin          v0.10.0 + manifest hash
└── hooks            stub → check install
                          → run v0.10.0 hooks

every session        machine setup → v0.10.0 rules