Knows the auth decision
Captured the decision, cited the file, and had it reviewed. The record is complete and correct, and reachable from exactly one laptop.
~/.zephr/ledger.sqlite · machine A
Use cases / Team lead
One team.Four versionsof the truth.
Four developers, four editors, four private ledgers. Each answer sounds equally confident; only one of them is grounded. Shared memory is the fix — and it is planned, not shipped, which this page says at the top.
Team memory planned (managed cloud)local rules shippedteam memory plannedno date committed
one question · four ledgers
Claude Code
cap 3 — grounded
has the record
Cursor
unlimited — confident
no shared record
Codex
cap 10 — confident
no shared record
opencode
no constraint — confident
no shared record
the confidence is identical; only the grounding differs
Illustrative example — not live data
The problem you actually have
The same decision, made twice, a month apart.
A developer reasons through the auth flow in March and captures it. In April a second developer asks the same question in a different editor on a different laptop, gets a plausible answer, and captures that. Neither of them did anything wrong. You now have two records for one decision, no way to tell which is current, and no place to look that would have told either of them. The cost is not the duplicated hour. It is that the two records will drift, and the first person to notice will be whoever ships the bug that sits between them.
Two developers, one decision, twice
Each side is a separate local graph today. Nothing is wrong with either record — the loss is that neither one knows the other exists.
Re-invents the same decision
Asks the same question a month later, gets a plausible answer, and captures it fresh. Two records now exist for one decision, and nothing reconciles them.
~/.zephr/ledger.sqlite · machine B
The managed cloud closes this by making the reviewed belief shared, scope-bound, and governed. Until the tenancy and security gates pass, it stays open.
Illustrative example — not live data. Cross-developer sharing requires the managed cloud and its tenancy gate.
The divergence
Same question. Four confident answers.
Toggle the topology. On the left, four private ledgers produce four different answers with identical confidence. On the right, the planned shared ledger — one reviewed answer, visible to all four. The shared pane is drawn dashed because it is not built.
the question:why does the webhook handler cap retries at 3?
Priya · Claude Code
March
Exponential backoff, cap 3 — the retry storm took the queue down in February.
source: ledger.sqlite · the February incident, reviewed
Marcus · Cursor
April
Unlimited retries with backoff should be safe here.
source: this machine only · no shared record
Ana · Codex
April
Cap at 10 and page on exhaustion — reads as the safer default.
source: this machine only · no shared record
Jonas · opencode
May
Depends on the provider; no constraint is visible from here.
source: this machine only · no shared record
illustrative — the four answers are the structural point, not real conversations
How it works for a team
Rules, then shared memory, then sync.
The route from per-developer continuity to shared memory runs in this order because each step needs the one before it. Every step is a plan gated on evidence, not a slot on a calendar, and only the first is partly built. Shared memory without a rule contract would just be a faster way to spread an unreviewed claim across three machines, and sync without shared memory would replicate three private histories rather than reconcile them.
- 01
Shared project rules
Rules move from advisory files to governed policy. The Trust Firewall evaluates them before retrieval rather than apologising afterwards. Partly shipped: the rule contract exists, organization-wide policy does not.
- 02
Team-scoped memory
Beliefs bind to the project and its ref topology rather than to one user, so an admitted teammate inherits the reviewed set. Requires the managed cloud.
- 03
Cross-machine sync
The managed cloud stores the evidence graph and encrypted source manifests. Local mode remains the offline alternative, not a downgrade path. Requires the managed cloud.
zephr rules --list --worktree feat/authDeveloper A
feat/auth · machine A
A reviewed auth decision, cited to the file it rests on.
Developer B
fix/session · machine B
The same decision, re-derived a month later and never reviewed.
Developer C
feat/billing · machine C
A contradicting note about the same flow, captured in good faith.
Every seat already produces a cited, dated record. What is missing is the place all three arrive at, where one of them is marked reviewed and the other two learn that they were superseded rather than sitting quietly beside it.
Designed, not built. Requires the managed cloud.
All three steps planned (managed cloud)No ship date is committed for any of them.
What applies to you
Three of these you can use today. Three you cannot.
Every developer already has local continuity and a common tool contract, and the record format is the one a team tier would share. The shipped capabilities come first. The three that would make this a team product are named plainly as unbuilt. Reading the split honestly is worth more to you than a badge row: it tells you which of your problems this solves this quarter and which of them you still have to solve with people.
Project rules via zephr_rules
ShippedWorktree-scoped review and contradiction policies that every connected tool reads through the same contract, instead of an advisory file each client may or may not honour.
versioned tool contract · CI-asserted
Local evidence graph per developer
ShippedEach developer already carries their own admitted scope and provenance chain. The record format is the one the team tier will share — not a throwaway local variant.
core evidence graph · ADR-012
TrustBench suite
ShippedCI-blocking deterministic tests the team can run before any cloud claim exists. Trust behaviour is verified in your pipeline, not asserted in ours.
deterministic suite · ADR-013
Team-scoped recall
Planned (managed cloud)Shared verified beliefs, filtered by review state and organization admission, so a teammate inherits what was reviewed rather than everything that was ever captured.
gated on the ADR-010 tenancy gate
Cross-machine sync
Planned (managed cloud)Outbox up, delta pull down, with organization-tenant isolation adversarially tested before any external user exists.
gated on the ZEP-1 security review
Collaborative review
Planned (managed cloud)A shared review queue, contradiction resolution, and approval receipts as durable objects rather than chat messages.
Review Phase B · designed, not built
Shipped capabilities run locally. Team-scoped capabilities depend on the managed-cloud security review (ZEP-1) and partner readiness (ZEP-231).
The daily loop
What changes about your week.
Today what changes is smaller than you want: the rules your team works under stop being a file each tool may skip and become a contract every connected client reads, and each developer's own history stops evaporating between sessions. What does not change yet is the part you asked for. A teammate still cannot inherit a reviewed decision, and until the tenancy gate passes there is no honest way to tell you otherwise.
Read the trust model.
The trust and security page explains how Zephr governs scope admission, review state, and audit receipts — the primitives team-scoped memory will be built on.