4SYNC ARCH

Questions

These are the questions to ask before deciding whether 4SYNC is worth your time. The answers include the parts that count against it.

Is there working code behind this, or is it a file convention?

Working code. Seven structural guards that run on every tool call, a close-time checker that audits the project's own bookkeeping and reports what has gone stale, a boot-cost meter, a reader that pulls measured session cost out of Claude Code's own transcripts, an updater that applies a release and proves it landed, and a one-time migration script for an existing ledger, and cross-project mail. 914 unit tests cover them.

The convention is the part you read; the code is the part that keeps the convention honest when you stop paying attention.

What does it do that a well-written CLAUDE.md doesn't?

It survives a second surface. One session with good notes is genuinely fine. The problem starts when two things touch the same folder — Cowork editing files it cannot commit, Claude Code with no idea that happened, a scheduled job running overnight.

That is where most of what is distinctive here comes from: a queue for handoffs a sandboxed session cannot make itself, sentinels that catch a read clipped by a mount, and a post-write check so one session does not quietly revert another's edit.

Who is it not for?

If one context window comfortably covers your project, or you only ever work in a single session on a single surface, the setup will cost you more than it returns. There is no version of this that is worth twenty minutes of configuration for a project you finish in an afternoon.

Are the guards a security control?

No. The hook runs in the same trust domain as the files it guards, so anything an agent can reach, an agent can route around. They exist so a change to your project's identity documents does not happen quietly — not so it becomes impossible.

Git plus review is still the boundary for deliberate change. The guards make sure nothing arrives at that review unannounced.

What happens if two sessions run at once?

They see each other. Each session records that it is live, and the next boot reports whether anyone else is currently working in the same instance, so a session knows the shared files are contested before it starts editing them.

Two caveats worth having up front. That visibility depends on the hooks being wired, so it is the one part of "optional" hardening that stops being optional the moment you run more than one session. And the file holding live state is the one place concurrent edits can still lose something, because it is the only file whose write mode invites replacing it wholesale rather than amending it.

What leaves my machine?

Nothing. There is no service, no account, no telemetry and no network call after the initial clone. The files sit in your repository and your agent reads them.

If you later want a second opinion on a running instance, the repo includes a read-only diagnostic you run yourself; it produces a report, shows it to you, and sends nothing. Mailing it is your decision and a separate step.

How long does adoption take?

Not five minutes. It is several files, a YAML manifest, hook wiring, and a long README. Budget an hour to understand what you are agreeing to.

What you do not do is install anything — no package, no plugin. The protocol itself needs no per-machine setup; the optional guard hooks are the one per-machine part, wired once per machine by scripts/wire_hooks.py. The first session interviews you and writes the configuration itself, and it plays back what it understood and waits for your go before writing a thing.

Is it reversible?

Delete the folder. The files are plain text in your repository and your git history, readable without any of our tooling. There is nothing to cancel and no export to request.

What do I need installed?

Claude Code, Git, and Python 3.8 or later using the standard library only — no pip install, ever.

One honest exception: YAML parse validation in one guard uses PyYAML, which is not in the standard library and is absent from a fresh Python. Without it that single check is skipped and the guard's other two checks still block. The test suites are green either way.

Is it open source?

Source-available. The license is FSL-1.1-ALv2, which is not OSI-approved, so calling it open source would be wrong. You can read it, run it, modify it and build on it; you cannot repackage it as a competing product. Each release converts to Apache 2.0 two years after it ships. The marks are not licensed.

What does it cost?

The product is free. There is no paid edition and no tiers.

ARCH Support is $200/hr, and defined pieces of work are quoted fixed-fee. Sending a diagnostic report and getting a work plan back costs nothing.

Check any of this yourself

Every answer above is verifiable before you commit a project to it, and it is reasonable to want that. Clone the repository, run the suites, and read the guard file — nothing here needs an account or an API key, and nothing writes outside the folder you cloned into.

git clone https://github.com/SandmanCircles/4SYNC-ARCH
cd 4SYNC-ARCH
python -m unittest discover -s hooks   -p "test_*.py"   # the guards
python -m unittest discover -s scripts -p "test_*.py"   # the tooling
python scripts/meter.py --dir . --json                  # boot cost, per file

Then read these three, which are where the claims above would fail if they were going to: