What an Old Process Still Runs

Landed Is Not Running

Lesson 2 separated code on disk from code in memory. That separation does not go away after a cutover; it shapes every later change. Contract v7, the rule that no write deletes a soul's identity note, landed on origin on the evening of 2026-11-10. The architecture document then does something unusual for a design document: it says exactly where the new rule was running, and where it was not.

Who Runs the Rule When

A fresh process runs it at once, once its Mac's checkout has followed origin: the soul-vault client, the canary, every harness bootstrap. These start for every task and import whatever is on disk.
A process that imported Soul Vault earlier keeps the v6 template until it restarts: pippa-serve and the other in-process consumers, and the Delta share on the canonical Mac, until Delta there reloads its shares or restarts.

Which leads to a precise, slightly uncomfortable statement of protection during the rollout. A delete of an identity note was still refused whenever the caller was a fresh v7 client, because its own template refuses before sending. It was still accepted from inside an old process, or from a Mac whose client was still v6 sending through a share that was also still v6. The rule was not on or off; it was on along some paths and off along others, for a while.

The Rollout as Observed

At 18:40 KST the document recorded the state per machine: v7 with its final fixes on the workbench, the Pippa machine (which follows origin by itself), the MacBook (pulled) and Pippa's home Mac (its follower); v7 without those fixes on three of the five mirror Macs, carried there by another session's sync that evening; still v6 on the other two mirrors until the next daily mirror run or a sync. pippa-serve had started at 18:04, before the rule; the Pippa machine's Delta had loaded its shares at 17:21. Both were Dad's to restart or reload.

One more line in that section is worth noticing. The session that built v7 tried to reload that Delta's shares and to sync the mirrors itself, and its harness's permission rules refused. The document records that those attempts "were refused ... and were not worked around". A session that cannot do a step reports the step as not done, with the reason, and leaves it to the person whose step it is.

The Same Shape in a Test Suite

Consumers' test suites showed the same effect from another angle. A full cold run of cwkPippa's suite against Soul Vault reported hundreds of setup errors at one point. Most traced to one cause: a fresh store fixture needed a .gitattributes file to stay visible to git, an omission one Soul Vault commit had introduced and a later one fixed. But a test process that had already imported the older implementation did not pick up the fix when a follower advanced the sibling checkout underneath it. A later run was rejected as evidence for exactly this reason: Soul Vault's checkout moved during the run, so the run did not test one version.

How to Report a Change Honestly

The lesson for anyone shipping changes to libraries that long-running processes import: "merged" and "pushed" are facts about origin. "Running" is a fact about each process, and it has to be observed process by process: the host's checkout must hold the commit, and the process must have started after that checkout moved. The commit's own timestamp is only a lower bound; a process started after it on a Mac that had not pulled yet still runs the old code. A report that says "v7 is live" when three processes still run v6 is not a small rounding error. It is a statement that some protection exists where it does not.

Code

Is this process running the code that landed? (sketch)·bash

# 1. does this Mac's checkout hold the change at all?
git -C <checkout> merge-base --is-ancestor <commit> HEAD && echo "present here"
# 2. when did the checkout first hold it? the oldest reflog entry that already
#    contains the fix (the commit's own time is only a lower bound; later,
#    unrelated pulls must not count)
git -C <checkout> reflog --date=iso --format='%H %gd' | while read -r sha when; do
  git -C <checkout> merge-base --is-ancestor <commit> "$sha" && echo "$when"
done | tail -1

# when did each long-running consumer start?
for label in <each service label>; do
  pid=$(launchctl list | awk -v l="$label" '$3==l {print $1}')
  [ -n "$pid" ] && echo "$label pid $pid started $(ps -o lstart= -p "$pid")"
done
# started before the fix arrived -> still runs the old template until it restarts.
# Even then, ask the process what it imported when it can say; timestamps only narrow it.

Where v7 protected, during its rollout·text

caller                         share on canonical Mac   delete of an identity note
-----------------------------  -----------------------  ---------------------------
fresh v7 client                any                      refused by the caller
old process (imported v6)      v6 (not yet reloaded)    ACCEPTED
Mac whose client is still v6   v6 (not yet reloaded)    ACCEPTED
Mac whose client is still v6   v7 (reloaded)            refused by the store
any (v7 pulled, restarted)     v7 (reloaded)            refused

Exercise

For a recent safety-relevant change to a shared library, build the 'where does it run' table: every long-running process that imports the library, its start time, the commit time of the change, and whether it runs the new code. Include any service that serves the library's logic to other machines. Then write the one-paragraph status you would send, stating exactly which paths are protected and which are not yet.

Hint

Do not forget proxies and shares: a server that applies requests on behalf of other machines runs its own copy of the logic, and an old copy there can accept what every new client would refuse.