Code vs State

"Code travels by git. State travels by API. A synced folder is neither."

Two Rails That Must Never Cross

Recall runs the same code on two hosts, and each host holds different live state. There are exactly two channels for moving things between them, and confusing the two is a classic way to poison a distributed system:

Code moves by git. You edit on the dev laptop, push to a private repository, and each host pulls independently. Every host converges on the same committed code. Git is the deployment channel.
State moves by API. The executor submits results to the control plane through authenticated API calls. The database on the control plane is the only place runtime state is authoritative. The API is the state channel.

That's it. Two rails. And the rule is that a third thing — a file-sync service, a shared folder, an exported Markdown file — is neither a code channel nor a state channel. Recall is explicit about it: file synchronization and generated Markdown are not deployment or runtime-state transports.

Why the Synced Folder Is a Trap

It looks so convenient. Both hosts can see the same synced folder, so why not drop state there and let it replicate? Because a sync service gives you the one thing a source of truth must never have: ambiguity about which copy is real. Two hosts write the same file, sync produces a conflict copy, and now you have two 'truths' and no rule for which wins. Worse, a stale synced copy looks exactly like a fresh one — there's no committed transition, no version, no acceptance. It's a database with no owner. That's how you get a job that's 'done' on one host and 'pending' on another forever.

Markdown Is an Export, Not a Model

The same discipline applies to human-readable artifacts. Recall generates Markdown transcripts you can read — but that Markdown is an export, downstream of the real data. It never feeds back in as truth. Search doesn't read the Markdown; it reads the structured, timestamped segments in the database. The moment you let an export become an input, you've created a loop where a hand-edited or stale file can silently rewrite reality. Keep exports strictly downstream: state flows out to Markdown, never back in from it.

Code

Two rails, and the trap between them·text

CODE RAIL (git):
  laptop edit ─push─▶ private repo ─pull─▶ control plane
                                    └pull─▶ executor
  every host converges on committed code

STATE RAIL (authenticated API):
  executor ─submit result─▶ control plane DB  (authoritative)

NOT A RAIL (the trap):
  synced folder / exported markdown
  → ambiguous 'which copy is real?', no acceptance, no version
  → state flows OUT to markdown, never back IN

Exercise

Look at a multi-machine setup you know (a fleet, a CI runner plus a server, two laptops sharing a project). Ask: how does code get from one to the other, and how does live state? If either answer is 'a synced folder' or 'we copy the files,' find the ambiguity — what happens on a sync conflict, or when one copy is stale? Redesign so code rides version control and state rides an authoritative API with real acceptance.

Hint

The dangerous pattern is any state that lives in a place with no owner and no version — a shared drive, a Dropbox folder, an exported file that also gets read back. Ask 'if two machines disagree, what rule decides the winner?' A synced folder has no answer; a database with an acceptance step does.