sleep

Every other path into the notes stops two hops out. That keeps a one-line write from turning into an hour of graph rewriting, and it means the graph slowly loses shape and the scratchpads slowly fill with work nobody filed. This pass pays both off at once.

Run the whole thing without asking. Phases 1 to 5 read, analyze, and stage; nothing is committed and nothing is destroyed until the single approval in phase 6. Do not stop mid-run to confirm a finding, a merge, or a prune. The report is where those get raised.

This is the long pass, and it has a real budget. Phases 3 and 4 repeat until the graph stops moving. Four passes and a hundred agents against a week that produced a lot of notes is the intended shape, not a runaway: a bucket swept twice costs a few thousand tokens, an edge missed costs until next Sunday. Within the budget, never narrow a sweep, cap a bucket count, or call the vault converged to finish sooner.

The budget is 255 minutes of wall clock, 85% of the five-hour window. Phase 1 stamps the clock; check it between passes and never mid-pass. It buys breadth rather than depth on one subject, so spend it sweeping every bucket instead of taking a fifth opinion on one note.

The stamp measures this pass, not the window. A run invoked by hand into a session that has already been working gets less than 255 real minutes, so treat the number as advisory then, calibrate off what pass one actually cost, and say in the report that the budget was approximate.

Spend it only where a model is the cheapest thing that works. Every mechanical answer already sits in a script, and an agent re-deriving one is the waste this budget is meant to avoid. health.py resolves paths, finds prose mentioning a note without linking it, and scores every sources/ pair for similarity. buckets.py divides the vault into work. Read those numbers; do not pay an agent to recompute them.

Every agent prompt carries a call cap, a write scope, and the question it answers. "Go through this bucket" is neither a scope nor a question. Both columns are in the dispatch table and both belong in the prompt text, not just in your head.

1. Heartbeat

date +%s > <scratchpad>/sleep-start          # the budget clock, before any work
python3 $VAULT/.scripts/relink.py      # instruction and spec mirrors, first
python3 $VAULT/.scripts/health.py
python3 $VAULT/.scripts/buckets.py
git -C $VAULT status --short

relink.py runs first so a renamed skill or a new docs/technical-spec.md is mirrored before anything reads the vault. health.py re-execs itself under $NOTES_VENV when the system interpreter lacks markdown-it-py, so bare python3 is correct here

.

Record the numbers: mean out-degree, notes linking out to nothing, notes with no inbound link, the full unfolded list, the bucket roster. They go in the report as before-and-after, and a pass that did not move them did not work.

The vault is almost never clean. git status --short at phase 1 captures what was already modified before this run touched anything. Keep that set. Phase 5 stages by path, so any file in it carries unrelated edits into the commit, and the report has to name which staged paths those are.

Mechanical defects (fence, meta, em-dash, path) are notes-heartbeat's job, not this one. Carry them into the report as a count and a pointer.

A ledger already in the scratchpad means the last run died. Read sleep-ledger.md and git diff before doing anything else: resume at the pass after the last one it recorded rather than starting over, and skip every finding it already applied.

The working tree outranks the ledger on resume. Agents write during phase 3 and the ledger is only appended at the end of a pass, so a run that died mid-pass left edits on disk that no row describes. Read them out of the diff and carry them into this run's report rather than re-deriving or reverting them.

2. Harvest the scratchpads

Seven days of scratchpads hold research ledgers, audit pages, draft notes, and handoff documents. Most is disposable. Some is a finding that never reached the vault.

find /private/tmp/claude-501/*/*/scratchpad -type f -mtime -7 \
  \( -name '*.md' -o -name '*.html' \) -not -path '*/node_modules/*' | sort

Read them inline under about 15 files. A dispatch that hands back what one Read would have returned costs more than it saves, and a normal week lands well under that. Past it, one sonnet agent per project directory, each given its file list, a 20-call cap, and one question: what in here is a durable fact, a decision that converged, or a constraint the vault does not already hold?

Either way the answer is candidate notes with the evidence and the source path, or nothing, which is the common and correct answer.

Findings enter the report as proposed additions, and a harvested note that is clearly right gets written in phase 4 like any other finding so later passes can connect it. Nothing from a scratchpad is committed without passing through phase 6.

3. Fan out

This is pass one and it covers everything. Later passes re-enter here with a narrower set of buckets and the same table.

All dispatches go in one message. Every agent in a pass reads the same snapshot of the vault, and nothing is serialized to let one job see another's output. That is deliberate: serializing the dispatch would cost four round trips per pass and buy an ordering that phase 4 gets for free at apply time.

Give each agent its slice, the health.py output for context, its call cap, and a reminder that its final text is the return value.

Model is what the dispatcher always accepts. Effort belongs in the call too wherever the dispatcher takes it: high for everything above, low for Dupe.

Who writes, and how far

An agent that already has a note open pays almost nothing to edit it. Handing the same finding back costs the orchestrator a Read and an Edit at full context, and that round trip was over half of what a run spends. So the agents holding a bounded, private slice of the vault apply their own work, and the ones whose writes cross the whole vault do not.

An agent applies only what it would default-check. One edit, mechanically reversible, no second reading available. Anything where the resolution is a judgment call, where the note's whole subject is in question, or where two directions are defensible comes back unapplied, exactly as before. That bright line is what keeps the report honest: default-checked means applied, unchecked means never applied, and phase 6 does not have to unpick anything.

An edit that is not in the return does not exist. Every finding comes back either way, carrying applied or returned, the file, the claim, and the diff. An agent that edits silently has made a change nobody can review, and the report cannot show a row it never heard about. Say this in the prompt.

Sweep is one agent doing two jobs because they read the same notes. Finding a missing edge and finding a stale claim are different questions, and asking both of one agent costs a little quality on each. It is worth it: the read is the expensive part, and paying for a bucket twice doubles the largest line in the run. The two answers stay separate everywhere downstream, in the ledger, the apply order, and the report.

Read the counts off phase 1, never off this file. One Sweep per bucket, one Fold per group on the unfolded line, Dupe only for pairs in the middle bands. Whatever that arithmetic gives is the pass, and it grows with the vault. Later passes add to the total rather than replacing it.

Buckets

buckets.py divides topics/, analysis/, and projects/ into even, subject-coherent slices: 8 buckets of about 23 notes at the default target of 30. The subject signal is which index topic reaches a note, computed by reindex.placement off the link graph, where a hub is a topic citing five or more others and every note falls to the nearest hub within three hops.

Nothing is tagged and nothing may be. The tags: field was removed on August 7th, 2026, and the rule against writing one is in $VAULT/.claude/rules/notes.md. It had been the work split and was bad at it, one tag holding 39% of the notes while three held one or two, but the reason it is gone is that it could not be checked: a hand-written label is its own only evidence, so marketing held three Pilcrow notes and axiom held four notes that were not about AXIOM, and nothing detected either. A bucket derived from links cannot be wrong about the links.

A bucket is a whole hub at the right size, an even slice of one too big (cut along filename subject runs, so spectra-render-stall and spectra-render-clock stay together), or several small hubs merged. Both halves of a merge are visible in the output, so a bucket named pilcrow+axiom tells its agent it is holding two subjects and should not force edges between them.

The adrift bucket is the exception worth reading. Those notes sit more than three hops from any index topic, so they are grouped by having nothing in common rather than by sharing a subject. Its agent gets told that, and the useful finding there is which index topic should have been citing each one.

Keeping the index tier alive is this pass's job, because nothing else runs wide enough to see it. A broad index topic is what a tag used to be, machine and swift and graphics, holding a two-sentence overview and then a clause per note saying what it answers, grouped by the symptom a reader arrives with. $VAULT/.claude/rules/notes.md has the shape. Two findings come out of every pass: which adrift notes want a line in an existing index, and which cluster of five or more has no index at all and wants one written. The second is a Fold agent's job and comes back as a proposal, never applied early, since a new index topic changes how every later pass buckets the vault.

The split is deterministic given the vault, so a later pass sees the same buckets except where notes were added or deleted. The ledger records paths, never bucket indexes, since an index means something different after a prune.

The target is a wall-clock lever, not a cost lever. Per-agent cost grows faster than linearly in bucket size, because every turn re-bills the context the last read added, so bigger buckets roughly cancel the saving from fewer agents. What they buy is waves: 9 buckets fit one concurrency wave where 12 need two. Drop to -n 20 when a run is tight on tokens rather than on time.

The stale-claim half of a sweep

health.py paths proves a path string still resolves. It cannot prove a sentence is still true, and a note describing a hook, a permission, a flag, a count, a price, or a model ID outlives the config that justified it. That check belongs to no script and to no other skill, so it lives here.

Name the live sources in the prompt alongside the bucket: $VAULT/.claude/settings.json for hooks and permissions, the file itself for a count or a size, the repo for a module name or a CLI flag. The agent returns one line per stale claim: the note, the quoted sentence, what the live source says now, and the command that showed it. A claim it could not check inside its cap is reported as unchecked rather than dropped.

Since one agent holds both jobs, say in the prompt that these are two answers and not one: a missing edge and a stale sentence in the same note are separate findings that apply at different points in phase 4.

Correct the claim, never annotate it. A corrected note reads as one clean version, per $VAULT/.claude/rules/notes.md. A note whose whole subject is gone is a Prune candidate, not a Verify fix.

Harvest and Dupe never repeat. The scratchpads do not change while this runs, and sources/ is read-only, so their pass-one answers hold for every pass after.

The dupe pass

vault.py dedupes on the URL exactly and cannot catch one document reached by two URLs sharing no id: an arXiv preprint and its publisher DOI, a repo whose owner renamed it, a talk posted to two channels. health.py dupes proposes those from phase 1 and this pass judges them. Why it scores bodies rather than filenames is written in check_dupes; what matters here is that both numbers arrive on the line.

Band on those scores and pay only for the middle. A line reads dupe name 0.87 text 0.42 a.md ~ b.md, and nothing under 0.9 name or 0.35 body is reported at all, so the low end is gone before you look. Unrelated documents measure 0.000.

Only the last two rows earn a dispatch. Dispatch nothing when they are empty, which is the normal case: dupes returns zero findings on the current vault. When there are pairs, split them into at most 8 batches, one haiku agent each, all in a single message. Give each agent its pairs and one instruction: read the first 400 characters of both files (head -c 400), then answer whether they are the same document, with the frontmatter url and title as the evidence. Nothing else is read, and no agent opens a whole source.

Deciding is mechanical at that depth, which is why this is haiku's tier rather than a reasoning model's. Each agent returns one line per pair: same or different, the two paths, and the one field that settled it. A pair the script already settled is carried into the report with its score as the evidence, exactly like an agent verdict.

A same verdict is a finding, never an edit. sources/ is read-only, so a confirmed duplicate goes in the report as a proposed deletion of the later file with its citations repointed at the earlier, and it waits for phase 6. This is the one job the loop never applies early. When the two disagree on content rather than identity, they are two sources and the pair is closed.

The edge half of a sweep gets its mechanical part free from health.py prose. The judgment part is renames (git log --diff-filter=R --name-status -- '*.md'), surface-form drift, notes sharing an index topic, and two notes naming the same path or symbol without naming each other.

Folding by group, not by note

The unfolded line names dated passes, and dispatching one agent per name is the most expensive mistake available here. A dozen passes on one subject want two topic notes rather than twelve.

Group the names by the index topic nearest each, and dispatch one Fold per group, the same rule buckets.py uses on notes. buckets.py already printed that grouping in phase 1, so read it off there rather than recomputing it.

An agent holding a whole cluster is the point, not a concession to cost: passes on one subject fold into one topic note far better together than apart, because the contradictions only show side by side. Split a group only when its passes exceed roughly 60k tokens together, which neither of today's two does.

4. Apply what came back, then go again

Most of the pass is already on disk when it returns: every edge and correction inside a bucket, and every new topic note. What is left here is the vault-wide half, which is merges, prunes, harvested notes, the citations a fold wanted to move, and anything an agent returned rather than applied.

Apply that set as connect, then verify, then fold, then merge, then prune. Those are finding kinds and not agents: one Sweep returns the first two, and they still apply at their own points. Connect only adds edges and everything after it benefits from them, verify lands a correction before any topic note gets built on the old claim, and merging before pruning stops a delete from taking content that was about to be salvaged.

Every agent read the same snapshot, so no finding accounts for what another job was about to change, and a self-applied edit landed without seeing the others either. A finding whose input another job changed in this same pass is not applied. A fold citing a note merge collapsed, a connect edge pointing at something prune deleted, a verify correction to a sentence a merge rewrote: skip it, record it in the ledger as deferred by collision, and let the next pass's agents read the settled text.

A collision against an edit an agent already applied is the one case that needs a revert rather than a skip. Merge and prune are the only jobs that can cause it, both are orchestrator-applied and go last, and both already have to repoint links across the vault, so a self-applied edge inside a note they are about to collapse gets carried into the survivor or dropped with the loser like any other line. Nothing is lost either way, because the loop re-sweeps every bucket a change touched.

Resolve conflicts between agents by the Precedence hierarchy in $VAULT/.claude/CLAUDE.md. Two agents proposing opposite directions for one edge means neither understood it; put both in the report and let the owner call it.

Then apply the pass, so the next one reads the vault as it stands rather than as it was. A finding that is clearly right is in the working tree, written by its agent or by this step. A finding that is real but arguable is carried to the report unapplied, and every later pass treats it as not done. Prunes move to ~/.Trash/notes-prune-{timestamp}/ now rather than at the end, because a note still sitting on disk keeps pulling agents back to it, and their inbound links get repointed in the same step per .agent-instructions/pruning.md. Nothing is committed and nothing is rm'd; phase 6 is still the only step that cannot be walked back.

Re-run health.py graph at the end of every pass. Those deltas are the stop signal and the report's per-pass line both.

What one pass owes the next

A connect-only pass is the last pass. Anything that changed what a note contains, or that got deferred by a collision, earns another one.

Scoping pass two and up

Re-scope, do not shrink. Re-run buckets.py, then take every bucket holding a note the last pass wrote, merged, or pruned and sweep the whole bucket, not the changed notes alone: the edges a change makes possible live in notes the pass never touched. Add the inbound linkers of anything deleted, any subject the fold left partly done, and every bucket holding a collision deferral. Covering a bucket twice is cheap and missing the one note that moved is not.

Same models, same dispatch table, same caps, all of a pass's agents in one message. A pass that dispatches two agents when six buckets moved was scoped wrong.

The ledger

<scratchpad>/sleep-ledger.md, appended at the end of every pass: pass number, job, note path, verdict, whether it applied, was held for the owner, or was deferred by collision, and which agent wrote it when it applied. It is what the report groups by and the guard against a loop that undoes its own work. Write it to disk each pass rather than holding it in context, which a four-hour run will compact away.

• A note one job edited in pass N is not proposed for that same job again. Other jobs may still reach it.
• A pair judged once, merge or dupe, is never re-judged.
• A link a prune killed does not come back through connect.
• A finding held back for the owner stays unapplied through every later pass. Nothing gets quietly promoted.
• A collision deferral is the exception: it is meant to be reconsidered, and the next pass proposes it again against the settled text.

When to stop

Stop when one of these holds, and not before:

1. The pass applied nothing.
2. The pass applied only connect edges and deferred no collisions.
3. Everything the table above would hand the next pass is already in the ledger.
4. The next pass will not fit the budget. Check elapsed between passes and compare against what the last pass cost; a pass that ran 50 minutes with 40 left does not start.

echo "$(( ($(date +%s) - $(cat <scratchpad>/sleep-start)) / 60 ))m of 255m"

Written out each time rather than defined as a shell function, since nothing in the shell survives between calls.

There is no pass ceiling inside the budget. Convergence is real because the ledger only grows, so a run still turning up structural work after five passes keeps going while the clock allows. Never stop on a sense that this has gone on long enough, and never stop mid-pass: a half-swept bucket is worse than an unswept one, because the ledger will record it as covered.

A run that stops on the budget says so in the report, with what the next pass would have swept. It is also the one stop that can leave a prune's inbound links unrepaired, so run reindex.py before staging and repoint anything it reports as dangling.

The completeness read

Once the loop converges, dispatch one opus agent over the ledger and the final health.py with a 25-call cap and one question: what did every pass miss? A bucket no agent ever held, a note nothing reached, a subject folded and never connected, an unfolded cluster left unfolded with no reason given. Concrete work it names opens one more pass. Anything vaguer goes in the report as a named gap.

5. Report and stage

Write sleep_{MM-DD}.html to the session scratchpad. Copy references/sleep-report_example.html and replace only its content, keeping the CSS and the script exactly as they are.

Its shape is fixed: a vitals strip carrying each graph number with its delta, then one section per finding kind (Connect, Verify, Fold, Merge and prune, Harvest), each a table of findings. Connect and Verify get their own sections even though one agent found both, since a reader approving an edge and a reader approving a rewritten sentence are checking different things. Every row is a checkbox, a one-line claim, the reasoning under it, the file it touches, and a <details> diff where a diff exists. Default-check what should apply; leave a row unchecked when the finding is real but the resolution is arguable, and say why in the row. The footer emits Selected: / Deferred: for pasting straight back.

The loop adds three things and no new CSS:

• The subhead carries the pass count, the bucket count, the agent total across all passes, and elapsed against the 255-minute budget. When the budget is what stopped the run, it says so there and names what the next pass would have swept.
• The vitals strip gains one more <div class="v"> for passes run, and each pass's health.py graph numbers follow the strip as a <p class="sub"> per pass, so a reader sees where the movement happened.
• Rows run in pass order inside each job's table, and anything from pass two and up carries a <span class="tag">pass 2</span> in the Kind cell next to its existing tag.

Any row whose file was already modified before this run started carries a <span class="tag">was dirty</span> too, since staging it commits edits this pass did not make.

Gaps from the completeness read go in their own section at the end, unchecked, since a gap is a thing to look at rather than a change to apply.

Then stage, do not commit:

git -C $VAULT add <explicit paths>

Everything default-checked is already in the working tree, written either by its own agent in phase 3 or by the orchestrator in phase 4, and everything unchecked was never applied. Stage exactly the default-checked paths so the diff is real and readable. Nothing is committed here.

git -C $VAULT diff --stat before staging is the check that the two agree. A modified note carrying no report row is an agent that edited without saying so: read the diff, write the row, and note it in the report as unreported rather than staging it silently.

In chat: the graph numbers before and after, the pass count, the finding count by kind, the count of staged paths that were already dirty, and the report path. Nothing else.

6. One approval, at the end

Ask once with AskUserQuestion, multi-select, three independent items rather than one bundled yes:

1. Commit the staged changes to $VAULT
2. Clear the scratch
3. Cancel the next scheduled run, offered only when this pass was invoked by hand rather than by the schedule

They are independent because their reversals are. Declining the commit reverts this run's working-tree edits and restores every prune from ~/.Trash/notes-prune-*/ to its path. Declining the clear does none of that; it leaves the scratch alone and nothing else changes. A single bundled refusal used to un-prune a vault over a disagreement about deleting temp files.

The clear never deletes the directory holding the report. The report lives in this session's scratchpad, which is inside the tree being cleared, so exclude it by name:

find /private/tmp/claude-501 -mindepth 2 -maxdepth 2 -type d ! -path '<this session dir>' -exec rm -rf {} +
rm -rf $VAULT/.claude/file-history/*

Last week's report goes with it, which is intended: the vault holds what the pass concluded, and the report is the interface for one approval rather than a record.

Prunes are already in ~/.Trash/notes-prune-{timestamp}/ from the pass that decided them, and nothing in this pass is ever rm'd. The scratch clear is the one real delete, and the report says how much it frees.

On approval: commit over explicit paths per $VAULT/.claude/rules/notes.md, clear the scratch, re-run health.py, and report the final numbers.

What this does not do

• Not a repair pass. Broken fences, bad frontmatter, dead paths: notes-heartbeat.
• Not research. Nothing outside the machine is read and no source is fetched. A gap worth filling is a finding, not a file to write from what a model happens to know.
• Never rewrites a source or a compass note. sources/ and compass/ are read-only here as everywhere, and a compass note is never a merge target, a prune candidate, or a fold destination. Where a pass finds the vault disagreeing with the compass, the finding is that the vault is wrong.
• Never deletes a transcript. $VAULT/.claude/projects/ and $VAULT/.claude/history.jsonl are the record of what was said; only scratchpads and file history get cleared.